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ABSTRACT 


This  thesis  develops  a  concept  and  initial  system  definition  of  a  Humanitarian  Aid 
and  Disaster  Relief  (HADR)  Operations  Management  Platform  (OMP)  that  supports 
various  stakeholders  involved  in  time-critical  humanitarian  response  efforts.  The  concept 
for  the  OMP  explores  the  various  functions  necessary  to  manage  HADR  operations  to 
include  facilitation  of  information  exchange,  collaboration  among  disaster  responders, 
and  a  common  operating  picture  (COP)  that  informs  decision  makers  of  the  operational 
environment.  The  development  of  the  OMP  uses  system  engineering  methodologies  and  a 
tailored  development  process  to  identify  the  requirements,  functions,  and  architecture 
necessary  to  support  the  platform.  The  OMP  concept  also  includes  multiple  data  sources 
for  near  real-time  information  and  support  tools  for  assessments,  planning, 
implementation,  execution,  and  evaluation.  This  thesis  also  assesses  advances  in 
technology  and  applications  to  more  effectively  support  and  manage  HADR  efforts.  As 
such,  the  OMP  takes  into  consideration  how  current  HADR  operations  are  conducted 
today,  and  the  role  of  virtual  volunteers  in  supporting  the  platform.  These  virtual 
volunteers  support  the  HADR  effort  by  conducting  tasks  virtually  via  their  computers  and 
an  internet  connection  anywhere  in  the  world. 
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EXECUTIVE  SUMMARY 


Advances  in  technology  such  as  information  systems,  crisis  mapping,  and  crowd 
sourcing  change  how  we  respond  to  humanitarian  aid  and  disaster  relief  (HADR)  efforts, 
and  provide  an  avenue  to  improve  the  management  and  effectiveness  of  HADR 
operations.  Large  quantities  of  data  are  becoming  available,  resulting  in  operations 
management  becoming  more  complex,  challenging,  and  critical.  HADR  operations  also 
require  working  with  a  widely  diverse  group  of  organizations  with  different  cultures  and 
languages,  different  standards  and  protocols,  and  competition  for  resources  (UN-OCHA 
2013,  24).  This  thesis  focuses  on  the  concept  development  and  initial  system  definition  of 
a  HADR  Operational  Management  Platform  (OMP)  for  use  by  various  stakeholders 
involved  in  a  time  critical  humanitarian  response  effort.  It  includes  inputs  from  multiple 
sources  of  information,  and  explores  ways  to  provide  information  and  tools  to  more 
effectively  manage  HADR  efforts. 

Currently,  there  is  no  single  consolidated  network-based  platform  that  provides  a 
common  operating  picture,  software  based  applications,  and  tools  to  aid  HADR 
responders  in  the  management  of  operations  in  a  rapid,  succinct,  and  coordinated  fashion. 
The  HADR  OMP’s  primary  mission  is  to  create  a  network-based  platform  to  rapidly 
provide  common  situational  awareness  and  management  tools  focused  on  the  early 
phases  of  a  HADR  event,  and  to  support  the  affected  people  impacted  by  the  disaster. 
The  ultimate  goal  is  to  efficiently  manage  HADR  operations  to  save  lives  and  alleviate 
human  suffering. 

Using  a  tailored  system  engineering  framework,  a  methodology,  procedures,  and 
tools  are  applied  to  develop  the  concept  and  initial  system  definition  for  a  HADR  OMP. 
This  includes  an  iterative  process  that  includes  mission  analysis,  problem  definition, 
identifying  key  stakeholders,  needs  analysis,  functional  analysis,  concept  development, 
mission  requirements,  and  architecture  development. 

During  the  concept  definition  phase  a  mission  analysis  is  conducted  by  first 
identifying  challenges  responders  face  in  HADR  operations.  Second,  a  mission  scenario 

xvii 


is  created  based  on  a  recent  HADR  event,  the  2015  Nepal  Earthquake.  From  this  mission 
scenario,  a  problem  statement  and  mission  objective  are  defined  and  an  operational 
concept  is  developed.  Also  from  the  scenario,  stakeholders  involved  in  the  HADR  event 
are  identified  and  their  needs  are  analyzed  and  prioritized,  producing  the  key  stakeholder 
needs.  From  these  key  stakeholder  needs  and  operational  concept,  the  measures  of 
effectiveness  (MOEs)  for  the  OMP  are  identified.  The  MOEs  help  define  how  well  a 
system  carries  out  the  operational  objective  within  specified  boundary  conditions 
(AcqNotes  2015). 

System  definition  is  the  next  phase  after  completion  of  the  initial  concept 
definition.  This  phase  includes  development  of  system  requirements,  logical  architecture, 
and  physical  architecture.  The  system  definition  begins  with  identifying  the  OMP  high- 
level  functions  required  to  meet  the  mission  objective  and  MOEs.  The  high-level 
functions  are  then  decomposed  into  lower  tier  sub-functions.  These  high-level  functions 
and  sub-functions  are  the  initial  foundation  for  system  requirements  and  the  logical 
architecture.  The  platform  functional  decomposition  is  focused  on  managing  and 
coordinating  HADR  operations  vice  developing  functions  to  conduct  every  aspect  of  the 
operations.  The  modes  of  operation  identified  in  the  operational  concept  are  used  as  the 
basis  for  many  of  the  high  level  functions.  The  modes  categories  include  needs 
assessment  and  analysis,  planning,  resource  mobilization,  implementation  and 
monitoring,  and  peer  review  and  evaluation. 

The  next  activity  in  the  system  definition  phase  is  developing  the  logical 
architecture  (also  known  as  a  functional  allocated  architecture)  of  the  HADR  OMP.  The 
logical  architecture,  defines  what  the  system  must  do  to  meet  the  functional  requirements 
identified  previously  (Buede  2009,  27).  The  logical  design  provides  the  major  functions 
and  system  boundaries  of  the  platform  along  with  their  relationships.  The  high-level  data 
flows  and  connections  are  also  defined,  and  the  HADR  OMP  software  applications  and 
system  support  components  are  identified.  An  organization  interaction  behavior  model  is 
developed  to  show  the  interaction  between  HADR  OMP  and  the  various  HADR 
responders,  the  host  nation,  and  the  affected  population.  The  initial  logical  architecture  is 
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used  to  ensure  all  components  and  functionality  necessary  is  accounted  for  and  is  well 
understood  within  the  platform  (TechieDolphin  2006). 

Next,  the  high-level  physical  architecture  was  developed  after  the  initial  iteration 
of  the  logical  architecture  and  includes  the  physical  infrastructure  necessary  to  support 
the  HADR  OMP  to  include  the  hardware,  software,  and  network.  The  computing  and 
network  hardware  are  identified  and  include  routers,  servers,  firewalls,  laptops,  backup 
hard  drives,  smart  phones,  tablets,  smart  watches,  and  deployable  backup  units  for  the 
primary  operation  centers.  Projectors  and  screens,  printers,  copiers,  fax  machines,  phone 
lines,  and  internet  connections  are  also  required  to  support  the  HADR  OMP.  A  software 
focused  reference  architecture  to  support  the  software  application  components  is  also 
identified,  and  includes  the  software  module  decomposition.  This  software  architecture 
more  specifically  addresses  the  information  management  function  of  the  HADR  OMP  to 
support  large  quantities  of  data  and  the  management  of  the  data  to  support  the  software 
applications  utilized  in  the  Graphical  User  Interface  (GUI).  The  HADR  OMP  network 
architecture  must  be  dynamic,  manageable,  cost-effective,  and  adaptable  to  meet  the 
mission  and  stakeholder  requirements.  For  this  reason  a  software-defined  networking 
(SDN)  architecture  with  distributed  computing  is  proposed  to  support  the  HADR  OMP. 

The  next  step  is  to  refine  the  concept  and  system  definition  by  receiving  feedback 
from  stakeholders  involved  in  HADR  operations  to  ensure  all  necessary  requirements  are 
captured  appropriately  and  that  the  proposed  solution  meets  the  needs  as  expected.  In 
addition,  partnerships  will  need  to  be  made  between  many  humanitarian  organizations 
with  agreements  for  sharing  data.  United  Nations  Office  for  Coordination  of 
Humanitarian  Affairs  (UN-OCHA)  would  need  to  endorse  and  lead  the  effort  on  creating 
the  platform  as  well  as  advocacy  from  multiple  humanitarian  response  stakeholders. 
Standards  for  data  sharing  will  need  to  be  agreed  upon  with  externals  starting  with  the 
Humanitarian  Exchange  Language  (HXL)  standard  as  the  baseline. 

Engineering  teams  need  to  be  created  to  further  define  the  solution  for  the 
platform.  This  includes  further  development  and  detailed  design  of  the  platform 
applications,  application  interfaces,  visualizations,  data  management  (including  “big 
data”),  network  architecting,  network  management,  software  management  services. 
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training  programs,  and  deployment  hardware.  Follow-on  research  and  trade-space 
analysis  should  be  conducted  to  more  thoroughly  assess  the  existing  platforms,  new  data 
sources  and  software  based  applications  that  can  be  incorporated  into  the  HADR  OMP. 

Finally,  the  system  definition  should  include  an  agile  software  development 
process  that  allows  for  expandability,  flexibility,  and  adaptability  with  open  source 
software.  A  prototype  should  be  created  to  aid  in  the  development  of  the  platform,  and 
allow  for  applications  to  be  added  easily  for  testing  for  functionality  and  interoperability 
with  already  existing  applications. 
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I.  INTRODUCTION 


The  evolution  of  mobile  technology,  social  media,  IT  networking,  and  big  data 
changes  how  our  societies  communicate  on  a  local  and  global  scale,  providing  a  wealth 
of  information  at  our  fingertips.  In  today’s  connected  and  technology  driven  world, 
utilizing  mobile  technology,  information  systems,  crisis  mapping,  crowd  sourcing,  and 
other  developments  in  technology,  can  help  save  lives  in  the  aftermath  of  a  humanitarian 
crisis  or  natural  disaster.  Humanitarian  Aid  and  Disaster  Relief  (HADR)  operations  can 
harness  these  technologies  to  improve  crisis  response.  These  technologies  supply  new 
capabilities  to  help  decision  makers  manage  operations  at  the  tactical,  operational,  and 
strategic  levels. 

For  example,  responders  use  social  media  in  disaster  relief  efforts  to  save  lives  in 
threatening  situations.  However,  there  is  no  single  consolidated  platform  that  takes 
advantage  of  the  new  advances  in  technology,  with  new  data  sources,  including  social 
media  and  drone  imagery,  to  help  personnel  manage  a  HADR  operation  that  is  networked 
and  interconnected  with  cross  flows  of  timely  communication.  This  thesis  uses  system 
engineering  methodologies,  processes,  and  tools  to  develop  an  operational  concept.  This 
thesis  also  develops  the  basic  functions  the  platform  must  provide  to  meet  mission 
objectives  and  requirements.  It  also  researches  various  technologies  and  information  that 
responders  can  use  to  support  HADR  operations  management  and  provides  possible 
solutions  for  incorporation  into  a  single  platform.  Research  is  also  conducted  on  how 
governments,  organizations,  and  individuals  respond  to  HADR  operations  today. 

A.  SCOPE 

The  scope  of  this  thesis  is  to  develop  an  operational  concept  for  a  Humanitarian 
Aid  and  Disaster  Relief  (HADR)  Operations  Management  Platform  (OMP)  that  takes 
inputs  from  multiple  sources  of  data  and  displays  them  in  a  way  that  aids  personnel  in 
managing  HADR  operations. 
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1.  Primary  Objective 

This  thesis  focuses  on  the  concept  development  and  system  definition  of  a  HADR 
OMP  to  be  used  by  various  stakeholders  involved  in  a  time  critical  humanitarian  response 
effort.  It  includes  multiple  sources  of  information,  and  explores  ways  to  provide 
information  and  tools  to  more  effectively  manage  HADR  efforts.  This  thesis  describes  a 
mission  scenario  based  on  how  HADR  operations  are  conducted  today.  From  this 
scenario,  an  operational  concept  of  the  system/platform  is  developed  to  aid  in  the 
definition  of  the  platform. 

2.  Secondary  Objective 

As  a  secondary  objective,  this  thesis  determines  whether  the  HADR  OMP  can 
also  incorporate  “virtual  volunteers”  to  aid  in  the  relief  efforts.  For  the  purposes  of  this 
thesis,  virtual  volunteers  are  defined  as  people  volunteering  their  time  to  conduct  tasks  to 
support  the  HADR  response  effort  via  their  computers  over  an  internet  connection. 

B.  RESEARCH  QUESTIONS 

This  thesis  works  to  solve  the  following  research  questions  listed  below  to  fulfill 
the  thesis  objectives: 

1 .  What  are  the  functions  and  operational  requirements  for  HADR 

operations,  and  how  can  these  requirements  be  managed  more  efficiently 
through  the  use  of  a  HADR  OMP? 

2.  What  type  of  data  and  technologies  can  be  utilized  to  support  a 
management  platform? 

3.  How  can  “virtual  volunteers”  most  effectively  be  utilized  to  help  in 
HADR  operations? 

C.  METHODOLOGY  OVERVIEW 

Using  a  system  engineering  framework,  a  tailored  methodology,  procedures,  and 
tools  are  applied  to  develop  the  concept  for  a  HADR  OMP.  This  includes  problem 
definition,  identifying  key  stakeholders,  needs  analysis,  functional  analysis,  concept 
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development,  system  requirements,  and  architecture  development.  Further  details  of  the 
framework  and  methodology  are  discussed  in  Chapter  III. 

D.  BENEFITS  OF  THE  STUDY 

The  benefit  to  developing  a  HADR  OMP  for  government  and  non-government 
organizations  is  the  potential  improvement  in  managing  HADR  events  which  can  save 
lives  in  the  process.  A  HADR  OMP  provides  new  ways  of  measuring  the  effectiveness  of 
relief  efforts  by  establishing  the  framework  to  analyze  the  collected  data  and  compare  it 
to  expected  levels  of  performance.  This  analysis  allows  HADR  leaders  and  participants  to 
learn  where  they  can  make  improvements  for  future  HADR  events.  Lastly,  the  HADR 
OMP  opens  new  doorways  for  “virtual  volunteers”  to  help  during  a  crisis. 
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II.  BACKGROUND 


A.  HADR  OVERVIEW 

There  are  a  multitude  of  events  that  can  create  a  disaster  that  requires 
Humanitarian  Aid.  According  to  the  U.S.  military’s  Foreign  Humanitarian  Assistance 
Joint  Publication  3-29,  these  events  are  caused  by  acts  of  nature  or  caused  by  human 
activities.  Examples  due  to  acts  of  nature  include  floods,  droughts,  fires,  hurricanes, 
earthquakes,  volcanic  eruption,  and  epidemics.  Human  activity-related  disasters  include 
riots,  violence,  civil  unrest,  acts  of  genocide,  and  war  (Joint  Publication  3-29  2014). 
Figure  1  provides  a  depiction  of  the  types  of  disasters  along  with  the  various  types  of 
humanitarian  services  that  may  be  required;  depending  on  the  severity  of  the  disaster. 


Figure  1.  Responses  to  Foreign  Disasters.  Source:  Joint  Publication  3-29  (2014). 

The  United  Nations  defines  a  humanitarian  crisis  as  “a  situation  in  which  the 

health,  lives  and  well-being  of  people  are  in  danger  as  a  consequence  of  the  disruption  of 
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their  daily  routine  and  access  to  basic  goods  and  services”  (UN-OCHA,  CMCS  2015, 
10).  Humanitarian  assistance  seeks  to  save  lives  and  alleviate  suffering  of  those  affected 
by  a  crisis. 

When  planning  to  respond  to  a  humanitarian  crisis,  it  is  important  to  keep  in  mind 
the  overall  objective  of  helping  those  impacted  by  the  disaster.  The  United  Nations, 
through  the  Inter-Agency  Standing  Committee  (IASC),  provides  humanitarian  principles 
to  help  guide  the  response  effort  to  ensure  that  the  responders  meet  the  overall  objectives 
without  biases,  hidden  political  agendas,  or  taking  of  “sides”  in  a  conflict  (UN-OCHA, 
CMCS  2015).  Table  1  provides  the  humanitarian  principles  that  responders  must  consider 
when  conducting  HADR  operations. 


Table  1.  Humanitarian  Principles.  Source:  UN-OCHA,  CMCS  (2015). 


Humanitarian  action  must  be  carried 
out  on  the  basis  of  need  alone,  giving 
priority  to  the  most  urgent  cases  of 
distress  and  making  no  distinctions  on 
the  basis  of  nationality,  race,  gender, 
religious  belief,  class  or  political 
opinions. 


Operational  Independence 


Humanitarian  action  must  be  autonomous  from  the  political,  economic,  military  or 
other  objectives  that  any  actor  may  hold  with  regard  to  areas  where  humanitarian 

action  is  being  implemented. 


Humanitarian  actors  must  not  take  sides 
in  hostilities  or  engage  in  controversies 
of  a  political,  racial,  religious  or 
ideological  nature. 


HADR  operations  are  complex  tasks  with  a  combination  of  efforts  from  multiple 
organizations,  many  of  which  have  overlapping  goals,  objectives,  and  responsibilities. 
These  organizations  do  not  only  include  U.S  agencies,  but  also  third-party  government 
agencies,  non-government  organizations,  international  organizations  and  Host  Nation 
agencies  (Joint  Publication  3-29  2014). 
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The  U.S.  military’s  Foreign  Humanitarian  Assistance  Joint  Publication  3-29 
describes  the  importance  of  coordination  and  cooperation  of  HADR  operations  with  the 
terms  “unified  action”  and  “unity  of  effort.”  These  terms  are  defined  as  follows: 

Unified  Action  is  the  synchronization,  coordination,  and/or  integration  of 
the  activities  of  governmental,  nongovernmental,  and  international  entities 
with  military  operations  to  achieve  unity  of  effort.  Unity  of  effort  is  the 
coordination  and  cooperation  toward  common  objectives,  even  if  the 
participants  are  not  necessarily  part  of  the  same  command  or  organization, 
which  is  the  product  of  successful  unified  action.  Unity  of  effort  in  an 
operation  ensures  all  means  are  directed  to  a  common  purpose.  (Joint 
Publication  3-29  2014, 1-2) 

This  unified  action,  also  known  as  a  unified  response,  can  be  a  challenge  in  real¬ 
time  operations,  but  is  critical  for  the  success  of  relief  efforts.  Situational  awareness  as 
well  as  effective  leadership,  management,  communication,  and  coordination  are  all 
imperative  in  time  sensitive  operations  where  medical  care  and  resources  are  essential  to 
those  affected  in  a  disaster  or  humanitarian  crisis  (Joint  Publication  3-29  2014). 

Figure  2  provides  the  various  humanitarian  stakeholders  during  a  humanitarian 
crisis.  The  stakeholders  include  organizations  from  the  Host  Nation  as  well  as 
organizations  providing  support  and  aid.  These  stakeholders  are  discussed  in  further 
detail  during  the  stakeholders’  needs  assessment  in  Chapter  IV. 
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Examples  of  Humanitarian  Assistance  Stakeholders 


Government 
Donors 

USG 

EU  and  Member  States 
Japan 

^Emerging  Donors" 


Private 

Sector 


Private 

Donors 


Diaspora 


*  Present  in  the  Middle  East 


Legend 

EU 

European  Union 

UNICEF 

United  Nations  Children’s  Fund 

ICRC 

International  Committee  of  the  Red  Cross 

UNRWA 

United  Nations  Relief  and  Works  Agency 

IOM 

International  Organization  for  Migration 

for  Palestine  Refugees 

NGO 

nongovernmental  organization 

USG 

United  States  Government 

OCHA 

Office  for  the  Coordination  of 

WFP 

World  Food  Program 

Humanitarian  Affairs 

WHO 

World  Health  Organization 

UNHCR 

United  Nations  Office  of  the  High 
Commissioner  for  Refugees 

Figure  2.  Humanitarian  Stakeholders.  Source:  Joint  Publication  3-29  (2014). 


B.  LESSONS  LEARNED  WITH  TECHNOLOGY 

Advances  in  technology  and  communications  change  how  we  respond  to  HADR 
efforts.  They  also  provide  an  avenue  to  improve  the  management  and  effectiveness  of 
HADR  operations.  As  organizations  incorporate  these  technology  advances  into  HADR 
operations,  the  world  is  also  learning  lessons.  Three  examples  from  more  recent  natural 
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disaster  relief  operations  include  the  Haiti  Earthquake  in  2010,  the  Typhoon  Haiyan  in 
2013,  and  the  Nepal  Earthquake  in  2015. 

One  key  technology  that  is  changing  the  landscape  of  response  efforts  is 
networking  and  communication.  In  2013,  the  Office  for  Coordination  of  Humanitarian 
Affairs,  under  the  United  Nations  (UN-OCHA),  conducted  a  study  titled, 
“Humanitarianism  in  the  Network  Age.”  This  study  emphasizes  the  criticality  of 
communication  in  HADR  events  and  how  advancements  in  communication  shape  the 
way  global  organizations  conduct  HADR  operations.  For  instance,  in  the  2010  Haiti 
earthquake,  various  agencies  that  supported  the  response  effort  did  so  with  their  own  data 
connectivity  equipment.  Significant  cost  could  have  been  saved  if  these  various 
organizations  shared  equipment  rather  than  each  having  their  own.  The  resulting  cost 
savings  could  have  freed  up  additional  funding  for  resources,  such  as  food,  water,  or 
medical  supplies  (UN-OCHA  2013). 

During  Typhoon  Haiyan  in  the  Philippines  in  November  2013,  there  were  over 
2000  response  workers  using  communication  services  that  were  coordinated  by  the 
Emergency  Telecommunications  Cluster.  By  making  these  services  more  predictable  and 
established,  it  can  help  to  reduce  costs.  In  addition,  it  would  provide  the  ability  to  train 
response  workers  on  established  protocols  with  the  communication  systems,  resulting  in 
more  effective  operations  (CD AC  Network  2014). 

The  Nepal  Earthquake  in  2015  is  the  most  recent  major  disaster  to  occur  during 
the  writing  of  this  thesis.  The  HADR  response  to  this  event  is  unprecedented  in  the 
number  of  new  technology  and  information  applications  utilized.  These  technologies 
include  real-time  satellite  imagery,  new  data  collection  tools,  virtual  volunteer  networks, 
and  crisis  mapping.  This  is  also  one  of  the  first  major  disasters  where  Unmanned  Aerial 
Vehicles  (UAVs)  are  widely  used  with  over  nine  independent  teams  flying  drones  over 
Nepal  to  support  the  response  effort.  However,  drone  operators  face  significant 
challenges  in  Nepal.  Without  an  understood  standardized  process  many  drone  operators 
did  not  register  with  the  Nepalese  government  and  face  arrest  and  confiscation  of  their 
equipment.  Lessons  learned  that  emerged  from  the  addition  of  new  drone  technology  is 

(1)  to  have  better  coordination  with  local  communities,  and  (2)  to  develop  a  shared 
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platform/repository  for  imagery  and  videos  being  collected  (Bollettino  and  Kreutzer 
2015).  A  humanitarian  organization  known  as  Team  Rubicon  also  deployed  to  Nepal  to 
aid  in  the  response  efforts.  An  additional  lessons  learned  from  their  assessment  is  the 
need  for  prioritized,  quantified  needs  information  to  responders  to  ensure  effectiveness 
and  minimize  duplication  of  effort  (Schwartz  2015). 
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III.  SYSTEM  ENGINEERING  METHODOLOGY 


This  thesis  utilizes  a  tailored  systems  engineering  approach  to  develop  a  concept 
and  system  definition  for  a  platform  to  effectively  manage  foreign  HADR  operations 
focusing  on  the  coordination  and  managing  of  resources  needed  in  the  initial  phases  of  a 
disaster.  It  also  provides  an  outline  of  the  tailored  systems  engineering  process  that 
addresses  the  system  functions  and  potential  solutions,  allowing  for  better  management  of 
HADR  operations. 

A.  SYSTEM  ENGINEERING  METHODOLOGY  AND  APPROACH 

This  thesis  utilizes  a  tailored  system  engineering  analysis  framework,  which 
includes  concept  and  system  definition  in  a  combined  top-down  and  bottom-up  approach 
to  develop  requirements,  functionality,  and  architecture  design. 

1.  Iterative  System  Definition  and  Analysis  Approach 

This  thesis  utilizes  an  iterative  system  definition  approach  that  links  the  problem 
statement  to  an  end  solution.  The  analysis  uses  background  and  lessons  learned  research 
to  aid  in  the  concept  and  system  definition  for  a  HADR  OMP.  In  addition,  this  process 
defines  the  high  level  functions,  requirements,  and  architecture  necessary  to  meet  the 
problem  statement  and  mission  objective  (ISO/IEC/IEEE  2015). 

Figure  3  shows  the  analysis’  concept  and  system  definition  approach.  It  includes 
mission  analysis,  stakeholder  needs  assessment,  and  requirements  phase  during  concept 
definition.  In  the  system  definition  phase,  the  system  requirements  are  defined  along  with 
the  development  of  a  logical  architecture  and  physical  architecture.  This  thesis  focuses  on 
the  initial  definition  of  the  system  as  a  starting  point  with  the  expectation  that  follow-on 
efforts  will  refine  the  definitions  as  the  concept  and  system  matures  with  feedback 
provided  by  stakeholders  (Faisandier  2012). 
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Figure  3.  Iterative  Approach  to  Concept  and  System  Definition.  Source: 

Faisandier  (2012,  230) 

2.  Top-Down  /  Bottom-Up  Development  Approach 

This  approaches  uses  a  combined  top-down  and  bottom-up  methodology  to 
develop  the  requirements  and  architecture  for  the  HADR  OMP.  From  a  top-down 
perspective,  requirements  are  decomposed  from  a  high  level  down  to  the  lower  levels 
with  an  emphasis  on  understanding  the  overall  system  and  how  it  aids  in  solving  the 
problem  statement.  From  a  bottom  up  perspective,  the  functionality  and  design  will  also 
be  developed  to  account  for  the  operational  environment  as  well  as  existing  technology 
that  can  be  incorporated  into  the  platform.  By  utilizing  both  these  approaches 
simultaneously  the  system  definition  focuses  on  meeting  user  needs  and  on  “whole 
system”  challenges  and  integration.  Based  on  the  Systems  Engineering  Body  of 
Knowledge  (SEBoK),  “Applying  Life  Cycle  Processes,”  Figure  4  shows  examples  of 
focus  areas  that  are  taken  into  consideration  while  developing  requirements  and  the 
architectural  design  for  the  HADR  OMP. 


12 


How  HADR  Missions 
Operate 

Strategic,  Operational, 
Tactical  Views 

Problem  Definition 

StakeholderNeeds 

Upfront 

Identify  Functions  of 
HADR  Operations 


Build  Common  Platform 
for  Multiple  Users 


Safety  Considerations 

Cultural  Considerations 

Resource  Considerations 

Local  Conflicts 

Feedbackfrom  People 
involved  in  HADR  events 

ExisitingTechnologies, 
Functionality,  and 
Processes  incorporated 
intothe  design 


ID 


£ 

o 


o 

CQ 


Figure  4.  Top-Down  /  Bottom-Up  Approach  to  Requirements  Development  and 

Architecture  Design  for  the  OMP 


a.  Top-Down  Approach:  From  Problem  to  Solution 

According  to  SEBoK,  “Systems  Approach  to  Solution  Synthesis,”  a  top  down 
approach  during  concept  definition  helps  to  define  she  problem  that  needs  to  be  solved, 
and  in  turn,  identify  the  operational  needs/requirements.  It  aids  in  better  defining  the 
solution  space  along  with  the  constraints/limitations  of  the  system.  After  the  mission 
context  is  defined,  the  top-down  approach  is  used  to  define  the  initial  design  solution 
related  to  meeting  the  operational  requirements.  It  is  important  throughout  the 
development  of  the  system  that  the  requirements  and  design  are  mapped  and  traced  back 
to  the  original  problem  statement  to  ensure  that  the  system  is  developed  to  meet  user 
needs  (BKCASE  Editorial  Board  2015). 

b.  Bottom-Up  Approach:  Evolution  of  the  Solution 

The  concept  and  system  definition  phases  also  takes  a  bottom-up  approach  in 

terms  of  incorporating  new  and  existing  capabilities  that  are  relevant  to  supporting  the 

needs  of  the  system  as  well  as  designing  the  system  to  have  feedback  mechanisms 

starting  at  the  lowest  level.  The  SEBoK,  “Systems  Approach  to  Solution  Synthesis,” 

explains  this  is  necessary  in  order  to  modify  or  adapt  structural,  functional,  behavioral 
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elements  to  optimize  the  effectiveness  of  the  system.  This  can  be  accomplished  by 
leveraging  existing  capability,  while  at  the  same  time  ensuring  growth  and  feedback 
within  the  system  for  future  capability.  The  bottom-up  approach  evaluates  the  initial 
design  considerations  and  functional  requirements  developed  in  the  top-down  approach, 
and  utilizes  existing  capabilities  to  meet  these  requirements.  A  form  of  “reverse 
engineering”  is  required  to  a  certain  extent  to  understand  the  current  systems  in  place, 
and  how  they  can  be  utilized  and  incorporated  into  the  new  system  in  development 
(BKCASE  Editorial  Board  2015). 

B.  SYSTEMS  REALIZATION  AND  DESIGN  CONSIDERATIONS 

This  thesis  focuses  on  concept  and  system  definition  previously  shown  in 
Figure  3;  however,  this  is  only  one  phase  in  the  development  of  realizing  a  deployable 
system.  Figure  5  shows  a  simplistic  view  of  the  activities  required  in  the  system 
realization  phase  with  the  goal  of  ultimately  deploying  a  system  that  meets  user  needs. 
After  completion  of  the  initial  system  definition,  follow-on  efforts  are  required  to  move 
into  the  system  realization  phase  which  include  the  implementation,  integration, 
verification,  and  validation  of  the  system  prior  to  deployment  (BKCASE  Editorial  Board 
2015).  The  initial  implementation  activity  includes  the  development  of  a  prototype  that 
will  aid  in  further  iterations  of  the  system  definition. 
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Figure  5.  Phases  of  System  Realization.  Source:  BKCASE  Editorial  Board  (2015). 
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IV.  CONCEPT  DEFINITION 


According  to  the  Systems  Engineering  Body  of  Knowledge  (SEBoK),  the  concept 
definition  phase  provides  understanding  of  the  problem  space  by  identifying  a  capability 
gap  or  opportunity  within  the  assessed  mission  environment.  The  mission  requirements 
and  stakeholders  are  examined  by  applying  systems  engineering  tools  and  processes.  The 
problem  statement  is  determined  during  mission  analysis,  where  the  stakeholders  are 
identified.  Then  the  stakeholders’  needs  are  defined  and  requirements  are  developed 
(BKCASE  Editorial  Board  2015).  Figure  6  shows  the  system  definition  process  that  was 
discussed  in  Chapter  III,  and  highlights  the  concept  definition  within  the  process. 
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Figure  6.  Concept  Definition  Phase  within  the  System  Development  Process. 

Adapted  from  Faisandier  (2012,  230). 

A.  MISSION  ANALYSIS 

The  mission  analysis  phase  defines  the  problem  space,  determines  the  scope  of 
the  effort,  and  identifies  the  limitations  and  constraints.  (BKCASE  Editorial  Board  2016). 
In  this  section  HADR  response  challenges  are  identified  and  a  mission  scenario  is 
developed  to  aid  in  analysing  the  problem  space. 
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1.  Challenges  with  HADR  Operations 

A  common  theme  within  the  research  is  that  better  communication  and 
coordination  between  all  parties  would  greatly  enhance  the  effectiveness  of  HADR  relief 
efforts.  A  review  conducted  by  UN-OCHA  identified  factors  hindering  effective  civil- 
military  coordination  and  developed  recommendations  to  break  down  the  hindering 
factors.  These  recommendations  came  from  a  review  of  Typhoon  Haiyan,  Cyclone,  Pam, 
and  the  Nepal  Earthquake  lessons  learned.  One  of  the  findings  concludes  the  following, 
“A  humanitarian  civil-military  coordination  capacity  in  domestic  (national)  and 
international  rapid  response  mechanisms  should  be  institutionalized  in  order  to  optimize 
interaction  and  interoperability  and  contribute  to  the  establishment  of  a  common 
situational  awareness”  (Reario  2015,  9). 

Communication  is  also  critical  and  paramount  when  HADR  organizations 
develop  a  response  to  a  disaster.  According  to  “Humanitarianism  in  the  Network  Age,” 
OCHA  Policy  and  Studies  Series,  2012,  the  traditional  model  that  responders  use  for 
managing  information  during  a  crisis  revolves  around  four  steps:  collect,  analyze,  decide, 
and  deliver.  Today,  HADR  operations  are  evolving  with  advancements  in  technology,  as 
more  and  more  organizations  and  people  want  to  help  during  a  disaster.  Large  quantities 
of  data  are  becoming  available,  resulting  in  HADR  operations  management  becoming 
more  complex,  challenging,  and  critical.  HADR  operations  also  require  working  with  a 
widely  diverse  group  of  organizations  with  different  cultures  and  languages,  different 
standards  and  protocols,  and  competition  for  resources.  (UN-OCHA  2013,  24). 

In  2010,  the  Nethope  Group  conducted  a  study  on  the  Pakistan  floods  that 
concluded  that  international  humanitarian  organizations  did  not  effectively  take 
advantage  of  information  accessibility.  Instead,  information  remained  quarantined  and 
was  not  always  disseminated  to  the  affected  communities.  The  root  cause  of  this 
deficiency  traces  back  to  the  lack  of  a  common  operational  picture,  lack  of  standards,  and 
lack  of  organizational  coordination.  There  was  also  poor  information  sharing  between 
HADR  responders  with  critical  disconnects  between  international  organizations  and  the 
host  country  district  authorities.  (UN- OCHA  2013,  24). 
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The  Logistics  Cluster  is  responsible  for  facilitating  the  unified  response  for 
logistics  activities,  and  includes  multiple  humanitarian  organizations  (Logistics  Cluster 
2015a).  A  challenge  identified  by  the  Logistics  Cluster  during  the  2015  Nepal  Earthquake 
concluded  that  operation  planning  was  hindered  by  the  following: 

An  incomplete  overview  of  the  requirements,  including  upstream  pipeline 
information,  future  needs  and  importance/prioritization  of  needs.  Though 
partners  were  requested  to  share  information  in  Nepal,  the  information 
provided  was  scarce.  This  affects  planning  and  use  of  resources  and 
creates  potential  accountability  issues.  (Logistics  Cluster  2015a) 

Incorporating  better  planning  tools  for  prioritization,  along  with  better 
monitoring,  information  sharing,  and  dissemination  into  the  OMP  ensures  that  responders 
use  resources  more  effectively,  minimize  duplication  of  effort,  and  ensure  accountability. 

Also,  during  the  Nepal  Earthquake  response,  responders  used  mobile  smartphone 
technology  to  provide  needs  assessments  and  monitoring.  However,  according  to  the 
Nepal  Earthquake  Appeal  Response  Review  provided  by  the  Humanitarian  Coalition, 
there  were  inefficiencies  in  the  large  amounts  of  information  exchanged  between 
organizations.  In  many  cases  the  information  was  poorly  communicated  and  overly 
complex.  This  leaves  opportunities  for  improvement  in  data  sharing  and  dissemination 
(Sanderson  et  al.  2015). 

Though  technology  is  becoming  more  accessible,  in  some  underdeveloped 
countries  there  is  a  risk  for  biases  within  the  data  collected  because  only  certain  people 
may  have  access  to  the  technology  to  provide  feedback  or  to  request  help.  These  biases 
include  gender,  education  level,  ethnicity,  religious  affiliation,  and  those  with  access  to 
technology.  In  certain  countries  there  is  the  potential  for  gender  bias  where  men  have 
greater  access  to  mobile  phones  and  the  internet  than  women  (UN-OCHA  2013,  20). 
Therefore,  it  is  important  to  ensure  that  there  are  multiple  methods  of  communication 
with  the  affected  population  to  ensure  proper  feedback  is  provided,  and  that  the  support  is 
not  directed  towards  certain  groups  of  people. 

Another  challenge  is  the  accuracy  and  utility  of  the  data  being  provided.  With  big 
data  and  automated  systems  being  developed  from  open-data  sources  the  risk  of 
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compound  errors  increase.  To  mitigate  this  risk,  the  OMP  needs  to  include  a  data 
validation  feature  (UN- OCHA  2013,  34). 

With  these  challenges  comes  room  for  improvement  with  new  technologies  that 
can  enhance  situational  awareness  by  creating  a  common  baseline  for  all  stakeholders, 
provide  faster  access  to  data  and  information  sharing,  more  accurate  response  to  the 
affected  population’s  needs,  real-time  feedback  from  responders  and  the  affected 
population,  a  greater  understanding  of  lessons  learned,  accountability,  and  greater 
involvement  from  communities.  Table  2  outlines  these  potential  opportunities  and 
impacts  and  what  stage  of  the  humanitarian  process  they  support  (UN-OCHA  2013). 

Challenges  should  not  hinder  the  advancements  in  HADR  operations,  but  instead 
should  be  acknowledged,  considered,  and  addressed  as  necessary  in  the  on-going 
development  of  a  new  HADR  OMP  to  include  new  applications  and  technology. 
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Table  2. 


Improvements  to  Incorporating  New  Technology  to  HADR 
Operations.  Source:  UN-OCHA  (2013). 


Stage 

Opportunities 

Impact 

Agreements  to  enable  automatic  access  to  key  data 

Faster  access  to  accurate  data  in  emergencies 

Preparedness 

Shared,  standard  country  profiles 

Common  baseline;  no  need  to 
re-gather  basic  information 

Needs 
assessment 
&  analysis 

Easy  sharing  of  information  across  needs 
assessments;  access  to  underserved  populations 

Reduced  duplication,  faster  assessments 

Real-time  verification  of  analysis  through 
two-way  communication 

Greater  involvement  of  communities  in  process 

Joint  planning 

Decisions  based  on  more  robust  analysis 
using  more  accurate  data 

Response  better  meets  needs 

Real-time  feedback  from  communities; 

Real-time  feedback  from  communities 

Resource 
mobilization 
&  allocation 

Greater  ability  to  access  and  track  sources 
of  funding 

More  accurate  budgeting  and  efficient 
use  of  resources 

Dynamic  re-allocation  in  response  to  changing 
circumstances 

Response  better  meets  needs 

Implementation 

New  partners  and  new  models  of  delivery 

Faster,  better  response 

Real-time  feedback  from  communities; 

Real-time  feedback  from  communities; 

Monitoring 
&  evaluation 

Better  cross-case  comparison  of  data 

Greater  understanding  of  what  works, 
what  doesn't  &  how  to  improve  action 

Real-time  feedback  from  communities 

Greater  involvement  of  communities  in  process 

2.  Mission  Scenario 

In  developing  mission  requirements,  an  operational  scenario  is  used.  During  the 
writing  of  this  thesis,  a  7.8  magnitude  earthquake  struck  Nepal  on  April  25,  2015, 
followed  by  aftershocks  and  another  7.3  earthquake  on  12  May.  Overall,  the  earthquakes 
killed  over  8,600  people  and  injured  over  100,000  people  (UN-OCHA,  Resident  and 
Humanitarian  Coordinator  for  Nepal  2015).  This  event  is  chosen  as  the  operational 
scenario  for  the  initial  concept  development  of  the  HADR  OMP  due  to  its  recent 
occurrence  during  the  writing  of  this  thesis,  and  also  due  to  its  relevance  with  one  of  the 
most  recent  HADR  events  available  where  the  use  of  new  technologies  were  used  to 
support  the  response  effort. 

One  of  the  main  concerns  during  the  response  effort  was  logistics.  There  is  only 
one  major  international  airport  in  Nepal  near  Kathmandu  and  it  has  only  one  airstrip.  This 
caused  congestion  at  the  airport  and  delayed  the  delivery  of  relief  supplies.  In  addition, 
Nepal  is  a  very  mountainous  region  and  many  people  were  affected  by  the  earthquake  in 
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remote  locations.  The  number  of  helicopters  was  very  limited.  Damage  to  the  roads  made 
the  task  of  providing  supplies  to  these  locations  even  more  difficult.  In  some  cases 
supplies  had  to  be  airlifted  or  transported  by  porter/pack  animal  transport  (Logistics 
Cluster  2015a).  Figure  7  provides  a  geographic  map  of  Nepal  displaying  the  epicenter  of 
the  2015  Earthquake. 


Figure  7.  Nepal  Map  Displaying  2015  Earthquake  Epicenter.  Source:  BBC 

(2015). 

3.  Problem  Statement  and  Mission  Objective 

Based  on  the  research  conducted  on  HADR  operations  which  included  identified 
challenges  and  lessons  learned  from  technology  and  the  mission  scenario,  the  following 
problem  statement  was  identified  for  the  OMP: 

The  overarching  goal  that  drives  the  conduct  of  all  HADR  operations  is  to  save 
lives  and  alleviate  human  suffering  through  efficient  management  of  information  and 
resources.  Currently,  the  ability  to  provide  this  efficient  management  is  lacking,  as  there 
is  no  single  consolidated  network-based  platform  that  provides  a  common  operating 
picture,  software  based  applications,  and  tools  to  aid  HADR  responders  in  the 
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management  of  operations  in  a  rapid,  succinct,  and  coordinated  fashion.  For  the  purposes 
of  this  thesis,  the  HADR  OMP  is  a  network-based  platform  that  includes  the  physical 
hardware,  software,  and  network  necessary  to  support  the  functions  to  effectively  manage 
HADR  operations.  The  following  mission  system  objective  is  developed  based  on  the 
identified  problem  statement: 

The  HADR  OMP’s  primary  mission  is  to  create  a  network  based  platform  to 
rapidly  provide  common  situational  awareness  and  management  tools  focused  on  the 
early  phases  of  a  HADR  event,  and  to  support  the  affected  people  impacted  by  the 
disaster. 


4.  Operational  Concept  Definition 

According  to  Buede,  an  operational  concept  is  “a  vision  for  what  the  system  is,  a 
statement  of  mission  requirements,  and  a  description  of  how  the  system  will  be  used” 
(Buede  2009,  196).  The  operational  concept  also  includes  the  high  level  interactions  with 
other  systems  (Buede  2009).  The  operational  concept  for  the  HADR  OMP  (or  rather  how 
the  system  will  be  used)  stems  from  the  scenario  and  research  conducted  on  how  HADR 
operations  are  conducted  today.  The  operational  concept  includes  the  modes  of  operation, 
the  interactions  in  the  operational  environment,  timeline  in  the  first  48  hours  of  initiation, 
identification  of  platform  boundaries,  external  system  interaction,  environment 
constraints,  and  the  use  of  virtual  volunteers. 

It  is  also  important  to  note  that  there  is  not  one  person  in  charge  making  decisions 
over  the  entire  HADR  operation.  Instead,  there  are  many  people  from  many  different 
organizations  that  have  to  make  decisions  continuously  throughout  the  response  effort  at 
multiple  levels.  Coordination  allows  everyone  involved  in  the  humanitarian  response 
effort  to  share  information  helping  to  ensure  that  the  affected  people’s  needs  are  met 
adequately,  and  allowing  humanitarian  actors  to  use  resources  more  effectively  and 
efficiently  (Harvard  Humanitarian  Initiative  2016). 
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a.  Operational  Modes 

The  operational  modes  of  HADR  operations  is  important  to  understand  to  ensure 
each  activity  is  accounted  for  within  the  OMP.  The  modes  of  operation  are  based  on  the 
Humanitarian  Programme  Cycle  (HPC)  elements  developed  by  UN-OCHA  and  endorsed 
by  the  IASC  (UN-OCHA  2015a).  However,  the  description  of  these  modes  are  modified 
from  the  HPC  elements  to  focus  on  the  management  of  HADR  operations  at  the  tactical 
level  versus  strategic  level.  These  modes  are  broken  into  five  different  categories  as 
shown  in  Figure  8.  The  mode  categories  include  needs  assessment  and  analysis,  planning, 
resource  mobilization,  implementation  and  monitoring,  and  review  and  evaluation. 

The  needs  assessment  and  analysis  mode  provides  rapid  analysis  of  the  overall 
crisis  situation  based  on  inputs  primarily  provided  by  HADR  responders,  host  nation,  and 
the  affected  population.  It  also  includes  country  specific  information.  During  this  mode 
needs  are  prioritized.  This  information  feeds  into  the  planning  mode  where  the  most 
pressing  needs  are  identified,  the  scope  of  the  response  is  determined,  roles  and 
responsibilities  are  established,  and  the  mission  objectives  of  the  relief  effort  are 
identified.  In  addition,  target  and  indicators  are  established  to  track  progress  and  ensure 
accountability.  This  planning  feeds  into  the  resource  mobilization  to  support  decision  on 
initial  tasking,  requests,  and  allocation  of  personnel  and  resources.  This  mode  also 
includes  the  status  of  these  resources,  and  feeds  into  the  implementation  and  monitoring 
mode.  The  implementation  and  monitoring  mode  provides  the  situational  awareness 
necessary  to  monitor  performance  and  identify  gaps  in  meeting  mission  objectives.  It  is 
also  where  the  implementation  of  the  response  takes  place.  Decisions  are  made  on  re¬ 
allocation  of  resources  real-time  to  support  dynamic  changes  impacting  prioritized 
objectives.  This  mode  is  also  coupled  with  the  coordination  and  collaboration  necessary 
to  support  the  HADR  response  (UN-OCHA  2015a). 

Though  the  modes  are  shown  in  sequential  order  it  is  important  to  note  that  these 
actions  happen  continuously  and  in  parallel  during  the  HADR  response  effort.  These 
modes  are  the  basis  for  the  high-level  functional  decomposition  of  the  OMP  and  aid  in 
identifying  the  various  components  necessary  to  support  the  management  of  these 
operations. 
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Figure  8.  Operational  Modes  based  on  the  HPC.  Adapted  from  UN¬ 
OCHA  (2015a). 

b.  Operational  Environment 

To  develop  an  OMP  it  is  important  to  understand  the  operational  environment  in 
which  the  platform  will  operate  and  the  relationships  between  the  various  elements. 
Figure  9  shows  a  graphical  representation  of  the  HADR  response  effort  at  the  high 
operational  view  level  known  as  an  Operational  View-1  (OV-1).  This  OV-1  shows  the 
operational  environment  the  OMP  will  need  to  operate  in.  The  HADR  response  includes 
providing  support  and  essential  needs  to  the  affected  population  with  shelters,  medical 
care,  and  aid  to  injured  or  trapped  victims  with  support  from  search  and  rescue  teams. 
Essential  supplies  are  needed  to  support  the  victims  such  as  food,  water,  and  medicine. 
These  supplies  are  transported  primarily  by  trucks  or  helicopters.  In  this  “Nepal” 
scenario,  water  transport  is  unavailable,  and  poses  a  challenge  for  transporting  supplies. 
Communications  are  essential  in  supporting  the  HADR  effort  and  are  provided  through 
radio  broadcast  towers,  satellite  communications,  internet  communications,  phone  lines, 
and  mobile  communication.  Drone  footage  and  satellite  imagery  is  collected,  and 
provided  for  analysis  to  support  the  operations. 
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Figure  9.  H ADR  Operations  OV-1 


The  airport  is  the  primary  Reception  and  Departure  Center  (RDC),  and  is  the  main 
point  of  entry  and  exit  for  HADR  responders  traveling  to  Nepal  to  support  the  response 
effort.  The  On-Site  Operations  Coordination  Center  (OSOCC)  is  responsible  for  rapidly 
providing  coordination  and  information  management  between  various  NGOs,  cluster 
teams,  foreign  militaries,  the  host  nation,  and  response  teams.  (UN-OCHA,  FCSS  2014). 
All  of  these  humanitarian  responders  make  decisions  that  impact  the  response  effort,  thus 
all  responders  have  access  to  the  HADR  OMP  with  the  OSOCC  as  the  primary  user. 

The  Multi-National  Military  Coordination  Center  (MNMCC)  facilitates  the 
collaboration  and  coordination  with  foreign  militaries  supporting  the  HADR  response, 
and  play  an  active  role  in  the  mobilization  of  resources.  The  National  Emergency 
Operations  Center  (NEOC)  or  the  Local  Emergency  Management  Authority  (LEMA)  are 
typically  run  by  the  Host  country.  The  NEOC/LEMA  is  responsible  for  the  overall 
command,  coordination,  and  management  of  the  response  operation,  and  works  closely 
with  the  OSOCC  (UN-OCHA,  FCSS  2014). 

The  operations  use  virtual  volunteers  to  analyze  satellite  and  drone  imagery  for 
infrastructure  and  damaged  roadways,  as  well  as  analyzing  Short  Message  Service  (SMS) 
texts  to  identify  specific  needs  of  the  population. 
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c.  First  48  hours  after  a  HADR  Event 

After  a  new  HADR  event  takes  place,  a  UN  Disaster  Assessment  and 
Coordination  (UNDAC)  team  is  deployed  to  assess  the  humanitarian  impact  as  well  as  to 
assist  in  the  coordination  of  incoming  international  relief  support.  The  UNDAC  members 
and  search  and  rescue  teams  are  on  standby  to  respond  within  12-48  hours  anywhere  in 
the  world.  The  virtual  OSOCC  is  setup  within  12  hours,  and  the  physical  OSOCC  is 
established  within  24 — 48  hours.  Figure  10  shows  the  UN-OCHA  response  nominal 
timeline  within  the  first  48  hours  after  a  crisis  occurs.  The  HADR  OMP  is  incorporated 
into  the  timeline  with  the  virtual  platform  operational  within  the  first  12  hours  (same 
timeline  as  the  virtual  OSOCC).  The  deployed  HADR  OMP  units  are  operational  within 
the  first  48  hours  after  a  crisis  begins.  These  units  are  deployed  to  the  OSOCC,  MNMCC, 
and  the  NEOC.  This  timeline  is  taken  into  consideration  when  developing  mission 
requirements  for  the  HADR  OMP  (UN-OCHA,  CMCS  2015). 


Figure  10.  UN-OCHA  Timeline  with  HADR  OMP  Incorporated.  Adapted  from 

UN-OCHA,  CMCS  (2015). 
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d.  System  Boundary  Definition 

It  is  important  to  define  the  boundaries  of  the  system  to  help  scope  the  problem 
and  better  define  possible  design  solutions.  The  context  diagram  shown  in  Figure  11 
defines  the  system  boundaries  compared  to  the  external  factors  that  will  interact  with  the 
platform.  These  interactions  are  essential  to  fulfill  the  mission  objective,  and  for  effective 
support  to  the  victims  of  the  disaster.  The  external  factors  to  the  OMP  include  data 
sources,  people,  logistics,  communication  nodes,  medical  support,  repair  of  critical 
services,  search  and  rescue  efforts,  and  survival  essentials.  Included  within  the  system 
boundary  of  the  OMP  is  platform  support,  training,  and  network  communications. 
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Figure  1 1 .  HADR  OMP  Context  Diagram 


e.  External  Systems  Diagram 

According  to  Buede,  an  external  systems  diagram  “defines  the  interactions  in 
terms  of  inputs  and  outputs  with  other  systems  and  is  consistent  with  the  operational 

concept”  (Buede  2009,  70-71).  It  is  important  to  identify  the  external  systems  that  the 
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HADR  OMP  will  interface  to,  either  for  inputs  into  the  system  or  as  an  output.  Figure  12 
shows  the  external  system  diagram  developed  with  potential  data  source  initial  inputs  and 
information  provided  to  external  users  via  a  graphical  user  interface.  However,  it  is 
important  to  note  that  the  platform  will  also  need  to  be  adaptable  and  expandable  to 
incorporate  new  input  and  output  sources  as  the  system  matures. 
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Figure  12.  High  Level  External  System  Diagram  with  Input/Outputs 


The  external  users  of  the  HADR  OMP  include  the  host  nation,  HADR  responders, 
virtual  volunteers,  and  the  affected  population.  These  users  are  seen  as  the  customers  of 
the  platform,  but  also  contribute  to  providing  the  information  necessary  for  the  OMP  to 
meet  its  mission  objective  and  MOEs. 

The  external  data  sources  at  the  high  level  can  be  broken  into  three  main 
categories:  unprocessed  data,  analyzed  data,  and  finished  products  and  reports.  The 
unprocessed  data  is  used  in  the  HADR  OMP  for  analysis  such  as  drone  imagery  foots  or 
satellite  imagery.  The  analyzed  data  is  data  that  was  analyzed  by  an  external  source 
before  being  provided  to  the  HADR  OMP.  This  includes  social  media  such  as  Twitter 
and  SMS  texts  pertinent  to  the  HADR  operations,  or  crisis  map  information.  Analyzed 
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data  can  also  include  crisis  map  information.  The  finished  products  and  reports  can 
include  needs  assessments  and  damage  assessments  provided  by  HADR  responders. 
Many  of  these  finished  products  can  be  provided  by  the  Humanitarian  Response 
Information  platform.  The  HADR  OMP  includes  a  common  operating  picture  for  better 
situational  awareness,  collection  management  and  analysis,  information  sharing  and  data 
management,  along  with  software  based  collaboration  and  functional  tools  to  support  the 
various  modes  of  HADR  operation. 

/.  Virtual  Volunteers 

Virtual  volunteers  can  play  a  critical  role  in  supporting  HADR  operations.  The 
advancements  in  technology  are  opening  a  new  doorway  and  opportunities  for  people  to 
help  in  disasters  remotely.  One  of  the  first  major  examples  of  virtual  volunteering  was 
during  the  Haiti  Earthquake  in  2010  (Meier  2010).  During  the  recovery,  a  group  of 
“virtual  volunteers”  through  a  system  of  SMS  messaging  and  social  media  aided  in  crisis 
mapping  efforts  to  help  victims  who  were  trapped  or  injured  during  the  disaster.  Virtual 
volunteers  known  as  the  Standby  Task  Force  were  also  utilized  during  the  2015  Nepal 
Earthquake  to  help  identify  urgent  needs,  infrastructure  damage,  and  response  efforts  to 
aid  in  situational  awareness  during  the  response  and  recovery  efforts.  Figure  13  shows  an 
example  of  the  crisis  mapping  developed  by  MicroMappers  with  the  Standby  Task  Force 
and  Qatar  Computer  Research  Institute  utilizing  Open  Street  Maps  (MicroMappers 
2015b). 
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Figure  13.  Example  of  Crisis  Mapping  Used  in  Kathmandu  after  the  Nepal 
Earthquake  in  April  2015.  Adapted  from  MicroMappers  (2015b). 

Figure  14  summarizes  the  texts  and  images  that  were  reviewed  during  the 
response  with  over  2,800  volunteers  contributing  to  the  effort  from  across  the  globe. 
These  volunteers  identified,  collected,  and  processed  234,727  images  and  55,044  Tweets 
about  damage  assessments,  needs,  and  deployments  in  Nepal.  The  HADR  OMP  will 
incorporate  the  ability  for  virtual  volunteers  to  support  the  relief  efforts  to  include  crisis 
mapping  (MicroMappers  2015a). 
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Figure  14.  Virtual  Volunteer  Support  the  2015  Nepal  Earthquake.  Source: 

MicroMappers  (2015a). 

Crisis  mapping  is  included  in  the  HADR  OMP  to  aid  in  providing  the  COP  as 
well  as  the  ability  to  incorporate  other  applications  that  virtual  volunteers  can  help 
support.  Figure  15  shows  the  potential  supporting  roles  that  virtual  volunteers  can  have 
during  a  HADR  response  effort. 
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Figure  15.  Virtual  Volunteer  Functions  for  HADR  OMP 


The  United  Nations  also  has  an  online  volunteering  search  engine  that  allows 
individuals  to  search  for  volunteer  opportunities  by  needed  task,  development  topics,  or 
by  region  where  support  is  needed.  These  opportunities  are  not  focused  on  immediate 
HADR  response  efforts,  instead,  they  are  focused  on  continued  humanitarian  support  in 
countries  where  continued  aid  is  needed.  However,  a  similar  approach  can  be 
incorporated  and  developed  for  HADR  operations  to  support  a  response  after  a  disaster 
occurs  (UN  2016).  Figure  16  shows  the  various  virtual  volunteer  opportunity  categories 
available  from  onlinevolunteering.org  as  well  as  the  regions  they  are  supporting. 
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Figure  16.  UN  Virtual  Volunteer  Opportunities.  Source:  UN  (2016). 

A  non-governmental  organization  (NGO)  known  as  the  Digital  Humanitarians 
(DH)  Network  brings  communities  together  by  facilitating  the  coordination  of  requests 
for  virtual  volunteer  support  from  traditional  humanitarian  actors  such  as  UN-OCHA, 
governments,  the  Red  Cross,  etc.  These  virtual  volunteer  organizations  provide  technical 
skills  in  support  of  humanitarian  response,  and  are  known  as  Volunteer  and  Technical 
Communities  (V&TCs)  (DH  Network  2016).  Figure  17  shows  the  interaction  between  the 
various  traditional  humanitarian  actors,  the  DH  Network,  and  the  V&TCs. 
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Figure  17.  Digital  Humanitarians  Community  Interaction  Diagram. 

Source:  DH  Network  (2014). 


g.  Design  Constraints 

Though  this  operational  scenario  is  used  to  help  determine  mission  requirements, 
the  system  will  not  be  limited  to  only  supporting  in  the  Nepal  region.  Depending  on 
where  a  disaster  takes  place  the  operational  environment  will  be  different.  For  this  reason 
a  HADR  OMP  must  be  capable  of  operating  in  various  types  of  environments.  This  will 
be  reflected  in  the  system  requirements,  and  will  influence  the  infrastructure/hardware 
that  will  be  used  to  support  the  system.  It  is  expected  that  many  disaster  areas  will  not 
have  adequate  infrastructure  to  support  the  HADR  OMP.  Therefore,  a  deployable  system 
must  be  part  of  the  platform  to  meet  system  requirements.  It  is  expected  that  a 
telecommunications  cluster  will  be  responsible  for  deploying  the  communications 
infrastructure  necessary  to  support  the  platform.  This  communications  infrastructure  is 
considered  an  external  interface,  however,  the  HADR  OMP  will  need  to  include  the 
network  infrastructure  to  support  the  platform.  Table  3  outlines  identified  system 
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requirements  and  possible  solutions  based  on  known  environmental,  technical,  and  local 
resource  constraints. 


Table  3.  Identified  System  Requirements  Based  on  Constraints 


Constraint 

System  Requirements 

Possible  Solution 

Environment 

The  HADR  OMP  must  be  a  capable  of 
operating  in  multiple  types  of 
environments  to  include  desert,  jungle, 
mountainous,  near  oceans,  etc. 

Utilizing  Military  Grade  Hardware 
capable  of  withstanding  extreme 
environments. 

Communications 

The  HADR  OMP  must  be  capable  of 
providing  adequate  network 
communications  between  various 
stakeholders 

Have  a  dedicated  team  to  deploy  the 
HADR  OMP  infrastructure 
necessary  to  support  the  platform  to 
include  the  network  hardware 
infrastructure  necessary  for 
collection,  analysis,  tasking/ 
requests,  information  management, 
and  dissemination, 

Develop  tools  that  aid  in 
collaboration  and  communication 
flow  within  the  OMP. 

Local  Resources 

The  HADR  OMP  will  make  use  of  local 
resources  to  the  greatest  extent  possible. 

The  HADR  OMP  will  coordinate  the 
needs  for  additional  resources  needed  that 
are  outside  the  ability  of  the  local 
resources  available. 

Incorporate  logistics  system  tool  to 
identify,  request,  track,  and  task 
needed  resources. 

Within  the  logistics  system,  setup  a 
mechanism/tool  that  allows  local 
businesses/communities/groups  to 
provide  information  on  the 
resources  available  for  purchase  to 
aid  in  the  effort,  (i.e.,  food,  water, 
shelter,  clothing,  machinery, 
medical  supplies) 

B.  STAKEHOLDER  NEEDS  AND  REQUIREMENTS 

The  next  activity  within  concept  definition  is  the  stakeholder  needs  and 
requirements  analysis.  This  activity  identifies  the  stakeholder’s  needs,  importance,  and 
priority.  Following  that,  mission  and  user  requirements  are  established.  Overall,  the 
purpose  is  to  ensure  that  the  development  of  the  system  meets  the  necessary  primary 
stakeholder  needs.  With  the  complexity  of  HADR  operations,  not  all  stakeholders’  needs 
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can  be  met.  Therefore,  this  analysis  will  prioritize  stakeholders  to  ensure  that  critical 
needs  are  identified  and  addressed  within  the  development  of  the  platform. 

1.  Stakeholder  Needs  Analysis 

Research  was  conducted  on  the  stakeholders  involved  in  HADR  operations  as 
well  as  lessons  learned  from  previous  HADR  events.  This  research  included 
documentation  policies,  guidelines,  and  procedures  by  well-established  HADR 
organizations  such  as  the  UN-OCHA.  The  stakeholder  needs  assessment  is  a  critical 
aspect  to  the  development  of  a  system,  and  ensures  that  the  needs  of  the  users  are  clearly 
identified  and  defined.  It  provides  an  opportunity  for  stakeholders  to  give  consensus  and / 
or  feedback  on  the  priorities  in  developing  the  system.  This  initial  assessment  is  the  view 
of  the  author  after  conducting  stakeholder  research  as  well  as  considerations  from  HADR 
challenges,  lessons  learned,  and  the  operational  concept  previously  described. 
Stakeholders  should  validate  this  assessment  in  future  efforts. 

This  section  shows  the  identified  high-level  needs  of  various  stakeholders 
involved  in  a  HADR  event.  The  stakeholders’  needs  were  prioritized  by  importance  for 
developing  a  HADR  OMP  from  one  (1)  through  five  (5),  with  five  being  the  highest 
priority  and  one  being  the  lowest.  The  stakeholder  analysis  uses  the  following  priority 
definitions: 

Priority  Five  is  any  group  that  has  been  deprived  of  basic  necessities  due  to  a 
disaster  and  requires  immediate  life-saving  assistance  (i.e.,  the  Affected  Population). 

Priority  Four  comprises  groups  that  exercise  command  and  control  over  HADR 
operations,  any  host  nation  group  that  provides  direct  support  to  victims  in  the  disaster 
area,  or  any  group  that  provides  direct  coordination  between  the  UN  and  HADR 
organizations. 

Priority  Three  groups  serve  a  necessary  communication  and  coordination  role 
between  governments  and/or  NGOs  during  a  HADR  event,  but  do  not  exercise  Command 
and  Control  and  do  not  expose  themselves  to  the  disaster  environment. 
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Priority  Two  groups  are  organizations  that  do  not  exercise  Command  and  Control 
and  do  not  expose  themselves  to  the  disaster  environment,  but  provide  logistical  support 
to  the  HADR  area  of  operations. 

Priority  One  groups  consist  of  any  stakeholders  that  do  not  meet  the  criteria  of 
priorities  two  through  five. 

This  stakeholder  needs  assessment  is  an  initial  examination  and  should  be  re¬ 
evaluated  with  feedback  from  stakeholders  to  ensure  that  the  needs  are  accurately  defined 
in  a  future  iteration. 

a.  United  Nations,  OCHA:  Priority  4 

The  UN-OCHA  is  responsible  for  the  overall  coordination  and  collaboration 
between  the  Host  Nation  government,  the  UN,  and  other  International  government 
Organizations  (IGOs)  and  NGOs  aiding  in  the  relief  efforts  (UN-OCHA  2015b).  UN¬ 
OCHA  needs  to  have  the  ability  to  coordinate  and  collaborate  effectively  with  other 
Humanitarian  Actors  aiding  in  the  HADR  efforts.  To  accomplish  this,  the  UN-OCHA 
must  possess  the  capability  to  collect  data  to  understand  the  severity  of  the  disaster, 
analyze,  and  respond. 

b.  Governments:  Priority  4 

Various  governments  involve  themselves  with  the  disaster  relief  efforts,  including 
the  Host  Nation  and  Supporting  Nations).  They  require  a  capability  to  maintain 
situational  awareness  on  the  status  of  relief  efforts  and  the  ability  to  make  decisions  based 
on  relevant  and  timely  information,  governments  also  need  to  understand  resource  gaps 
and  the  severity  of  the  situation  to  ensure  funding  and  resources  are  allocated 
appropriately. 


c.  Military  Support:  Priority  2 

HADR  operations  often  include  various  support  from  military  units.  These 
military  units  may  include  foreign  and  host  nation  support.  This  support  includes,  but  is 
not  limited  to  supplies,  logistics,  transportation,  and  medical.  Military  units  require  the 


38 


ability  to  adequately  collaborate  and  interface  with  the  Humanitarian  operations  to 
understand  how  to  best  support  the  response  effort.  This  includes  having  near  real-time 
information  to  adequately  respond,  understanding  gaps  in  resources,  establishment  of 
coordination  mechanisms  to  relay  status  of  activities,  and  requests  for  support  (Joint 
Publication  3-29  2014). 

d.  Emergency  Responders:  Priority  4 

The  first-line  defenders  in  HADR  operations  are  Emergency  Responders  such  as 
search  and  rescue  teams,  fire-fighters,  and  medics.  These  responders  must  have  a 
capability  to  have  timely  and  pertinent  information  that  provides  situational  awareness 
and  allocation  tasking  of  where  to  best  support  during  HADR  operations. 

e.  Other  IGOs:  Priority  2 

According  to  the  Joint  Publicatoin  3-29,  “An  IGO  is  an  organization  created  by 
a  formal  agreement  (e.g.,  a  treaty)  between  two  or  more  governments.  It  may  be 
established  on  a  global,  regional,  or  functional  basis  for  wide-ranging  or  narrowly  defined 
purposes.  It  is  formed  to  protect  and  promote  national  interests  shared  by  member  states” 
(Joint  Publication  3-29  2014,  11-11).  While  they  are  not  directly  involved  in  the 
operations,  they  do  require  information  and  status  of  the  response  efforts  to  be  adequately 
communicated.  The  HADR  OMP  is  focused  on  supporting  the  operations  from  a  tactical 
and  operational  level,  however,  the  OMP  will  also  need  to  provide  information  to  the 
strategic  level  to  aid  in  higher  level  decision  making. 

f.  NGOs:  Priority  3 

According  to  the  Joint  Publication  3-29,  “An  NGO  is  a  private,  self-governing, 
not-for  profit  organization  dedicated  to  alleviating  human  suffering;  promoting  education, 
health  care,  economic  development,  environmental  protection,  human  rights,  and  conflict 
resolution;  or  encouraging  the  establishment  of  democratic  institutions  and  civil  society” 
(Joint  Publication  3-29  2014,  xii). 

NGOs  need  to  be  informed  on  how  best  to  support  the  HADR  response  effort. 
This  can  include  tasking  and  resource  allocation.  Also,  NGOs  require  the  ability  to 
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provide  feedback  such  as  damage  assessments,  and  casualty  information.  Finally,  NGOs 
require  stronger  coordination,  compiling,  and  information  sharing  between  the  various 
actors  in  order  to  raise  issues  of  common  concern  hampering  the  response;  mitigate  any 
duplication  of  efforts;  and  maximize  the  use  of  available  people  and  resources  (Logistics 
Cluster  2015b). 

g.  Cluster  Members:  Priority  4 

According  to  UN-OCHA,  the  cluster  approach  is  a  needs-based  response  system 
that  focuses  on  various  functions  to  support  HADR  operations  to  include  health, 
protection,  food  security,  emergency  telecommunications,  early  recovery,  education, 
sanitation,  water,  hygiene,  logistics,  nutrition,  emergency  shelter,  camp  management  and 
coordination,  and  information  management.  These  various  clusters  perform  specific 
functions  or  tasks  and  can  be  activated  at  different  phases  of  a  disaster  (UN-OCHA 
2015c).  Cluster  Teams  need  information  management  and  situational  awareness  to 
support  operational  decision  making,  and  to  improve  the  efficiency  of  the  response  to  the 
operation.  These  services  need  to  include  consolidated  sharing  of  information  from  the 
humanitarian  community  and  local  authorities  on  the  overall  situation,  including 
logistical  gaps  and  bottlenecks  (Logistics  Cluster  2015b).  According  to  the  Logistics 
Cluster,  the  cluster  teams  require: 

1.  Updated  operational  information,  such  as  road  conditions,  warehouses  and 
customs  procedures  as  well  as  the  publication  of  situation  reports, 
bulletins,  snapshots,  flash  news  and  briefings. 

2.  Tools  and  products,  inclusive  of  specific  maps  related  to  logistics 
infrastructure. 

3.  Capability  to  monitor  the  situation  and  to  receive  updates  on  assessments. 
These  assessments  will  be  regularly  shared  with  the  humanitarian  actors  to 
ensure  efficient  delivery  objectives  (Logistics  Cluster  2015b). 

h.  Operational  Coordination  Centers  (OCCs):  Priority  4 

The  Operations  Coordination  Centers  (OCCs)  are  the  various  coordination  centers 
and  committees  activated  during  a  HADR  event  such  as  the  OSOCC,  MNMCC,  and  the 
NEOC.  They  require  a  HADR  OMP  that  can  be  used  by  various  stakeholders  that  are 
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involved  in  a  time  critical  humanitarian  response  effort.  This  platform  must  include 
multiple  sources  of  up-to-date  information  to  ensure  the  most  comprehensive 
understanding  of  the  situation,  gaps  is  resources,  and  needs  of  the  people  affected  by  the 
crisis. 


1.  Media:  Priority  3 

The  news  media  outlets  that  report  on  the  HADR  event  have  the  ability  to  support 
HADR  operations  by  distributing  needed  information  to  the  affected  population.  These 
media  outlets  need  to  be  provided  with  current  crisis  information  that  can  be  relayed  to 
the  people  involved  in  the  crisis. 

j.  Virtual  Volunteers:  Priority  4 

The  virtual  volunteers  associated  in  supporting  the  HADR  effort  need  to  have 
established  roles  agreed  to  and  understood  by  the  HADR  responders  responsible  for 
coordination  to  ensure  their  utility.  The  tasks  they  will  be  performing  will  need  to  be 
planned  for  within  the  design  of  the  OMP  to  ensure  the  appropriate  functionality  and/or 
external  interfaces  are  present.  This  can  be  achieved  with  existing  or  newly  developed 
applications.  Virtual  volunteers  need  the  ability  to  access  timely  information  to 

k.  Affected  Population:  Priority  5 

The  affected  population  is  the  victims  and  family  members  of  those  effected  by  a 
disaster.  Their  primary  needs  include  safety  from  harm,  locating  family  members,  and 
recovery  from  the  disaster.  They  also  require  adequate  food,  water,  shelter,  medical 
services,  and  support  if  injured  in  the  crisis.  Finally,  affected  populations  must  be 
informed  on  where  to  find  help  and  support  and  have  the  ability  to  provide  feedback  on 
the  relief  efforts  to  ensure  the  responders  are  meeting  the  needs  of  those  affected. 

2.  Summary  of  Key  Stakeholder  Needs 

After  analyzing,  prioritizing,  and  integrating  the  various  stakeholder  needs,  ten 
key  needs  were  identified.  These  key  stakeholder  needs  are  shown  in  Table  4.  These 
needs  are  critical  to  the  success  of  meet  the  objective  of  the  HADR  OMP. 
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Table  4. 


Key  Stakeholder  Needs 


No. 

Key  Stakeholder  Needs 

1 

Rapid  and  Persistent  Information 

2 

Enhanced  Data  Exploitation  &  Analysis 

3 

Enhanced  Common  Situation  Overview 

4 

Enhanced  Collaboration 

5 

Enhanced  Communication 

6 

Enhanced  Information  Collection 

7 

Enhanced  Metrics  and  Accountability  of  Ops 

8 

Interoperability  with  Existing  Systems  and 
Applications 

9 

Incorporation  of  Virtual  Volunteers 

10 

Sharing  of  Information  to  Affected  Population 

11 

Meet  Operational  Timelines 

12 

Meets  Environment  Constraints 

3.  Measures  of  Effectiveness  Requirements 

According  to  AcqNotes,  a  source  of  Department  of  Defense  (DOD)  acquisition 
knowledge,  Measures  of  Effectiveness  (MOEs)  “are  measures  designed  to  correspond  to 
accomplishment  of  mission  objectives  and  achievement  of  desired  results.  They  quantify 
the  results  to  be  obtained  by  a  system  and  may  be  expressed  as  probabilities  the  system 
will  perform.”  In  addition,  the  MOEs  will  help  define  how  well  a  system  carries  out  the 
operational  objective  within  specified  boundary  conditions  (AcqNotes  2015). 

According  to  the  Sphere  Project,  their  initiative  is  “to  determine  and  promote 
standards  by  which  the  global  community  responds  to  the  plight  of  people  affected  by 
disasters.”  Their  handbook,  the  Humanitarian  Charter  and  Minimum  Standards  in 
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Humanitarian  Response,  is  used  to  establish  the  minimal  standard  of  care  for  food,  water, 
hygiene,  shelter,  and  medical  for  the  affected  population  during  a  crisis  (The  Sphere 
Project  2015).  The  HADR  OMP  will  be  developed  in  a  way  that  will  allow  event  specific 
target  and  indicators  to  be  established  and  monitored  per  each  HADR  crisis  and  response. 

Based  on  the  mission  analysis  and  stakeholder  needs  previously  discussed,  a 
listing  of  the  identified  MOEs  for  the  HADR  OMP  are  developed  and  shown  in  Table  5. 
It  is  important  to  show  traceability  of  these  MOEs  back  to  the  mission  analysis  and 
stakeholder  needs  analysis.  By  showing  traceability  it  ensures  that  all  the  essential 
stakeholder’s  needs  are  met.  Table  6  provides  the  traceability  to  the  key  stakeholder 
needs  that  were  identified  previously  in  Table  4. 
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Table  5. 


HADR  OMP  Measures  of  Effectiveness 


MOE 

Description 

Objective 

Threshold 

1.0 

The  OMP  shall  provide  access  to  persistent 

situational  awareness  to  all  stakeholders  in 

supporting  the  HADR  response  effort. 

100% 

90% 

2.0 

The  OMP  shall  provide  timely  information  to 

enable  collaboration,  coordination,  and  decision 

making.  This  includes  the  ability  to  place  request 

or  task  resources. 

Near  real-time 

95%  Availability,  w/ 

90  days  storage. 

Within  2  hours 

70%  Availability,  w/ 

30  days  storage. 

3.0 

The  OMP  shall  be  globally  deployable  to  disaster 

locations.  This  includes  network  communications 

and  infrastructure  to  support  the  platform  offline. 

(Requires  a  point-of-presence  communications 

node) 

Virtual  OMP  within  6 

hours 

Physical  Platform 

within  24  hours 

Virtual  OMP  within 

12  hours 

Physical  Platform 

within  48  hours 

4.0 

The  OMP  shall  provide  metrics  for  accountability 

based  on  indicators  and  targets  agreed  to  by 

HADR  response  leads. 

Near  real-time 

Updates  every  2 

hours 

5.0 

The  OMP  shall  allow  virtual  volunteers  to  aid 

damage  and  needs  assessments,  and  to  sift  social 

media  for  response  efforts. 

10,000  Virtual 

Volunteers 

2,000  Virtual 

Volunteers 

6.0 

The  OMP  shall  provide  management  tools  to 

support  all  modes  of  operation  and  will  include 

enhanced  information  management  for  collection, 

processing,  analysis,  visualizations,  and 

dissemination. 

95%  Data  Accuracy 

85%  Data  Accuracy 

7.0 

The  OMP  shall  provide  Interoperability  with 

existing  systems  to  support  platform  functions. 

Interoperability  with 

established  HADR 

platforms 

Interoperability  with 

established  and  future 

platforms 

8.0 

The  OMP  shall  provide  up-to-date  relief  effort 

information  to  the  affected  population,  and  provide 

feedback  mechanisms  to  identify  needs  of  the 

affected  population. 

Updates  every  30 

minutes 

Updates  every  hour 
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Table  6 


HADR  OMP  MOEs  Traceability  Matrix 


HADR  OMP  MOE  to  Stakeholder  Needs  Traceability  Matrix 


Stakeholders 

Needs 

MOEs 

Rapid  and  Persistent 
information 

Enhanced  Data 
Exploitation  &  Analysis 

Enhanced  Common 

Situation  Overview 

Enhanced  Collaboration 

Enhanced 

Commini  cation 

Enhanced  Information 

Collection 

Enhanced  Metrics  and 

Ac  count  ability  of  Ops 

Interoperability  with 

Existing  Systems  and 

Applications 

Incorporation  of  Virtual 

Volunteers 

Sharing  of  Information  to 

Affected  Population 

Meets  Operational 

Timelines 

Meets  Environment 

Constraints 

1.0 

X 

X 

X 

X 

X 

X 

2.0 

X 

X 

X 

3.0 

X 

X 

4.0 

X 

5.0 

X 

X 

X 

6.0 

X 

X 

X 

7.0 

X 

X 

8.0 

X 
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V.  SYSTEM  DEFINITION 


The  next  phase  of  the  development  process  is  system  definition.  This  phase 
includes  development  of  system  requirements,  logical  architecture,  and  physical 
architecture  based  on  the  stakeholder  needs,  operational  concept  and  MOEs  identified 
during  the  concept  definition  phase.  Figure  18  shows  the  systems  engineering 
development  process,  and  highlights  the  system  definition  phase. 


Figure  18.  System  Requirements  Phase  within  the  System  Development 
Process.  Adapted  from  Faisandier  (2012,  230). 


A.  SYSTEM  REQUIREMENTS 

According  to  the  International  Council  on  Systems  Engineering  (INCOSE) 
Systems  Engineering  Handbook, 

System  requirements  are  all  of  the  requirements  at  the  system  level  that 
describe  the  functions  which  the  system  as  a  whole  should  fulfill  to  satisfy 
the  stakeholder  needs  and  requirements,  and  is  expressed  in  an  appropriate 
combination  of  textual  statements,  views,  and  non-functional 
requirements;  the  latter  expressing  the  levels  of  safety,  security,  reliability, 
etc.,  that  will  be  necessary.  (BKCASE  Editorial  Board  2016,  331) 
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These  system  requirements  begin  to  form  the  basis  of  the  architecture,  design, 
integration,  and  verification  activities  while  also  acting  as  a  reference  for  validation  of 
stakeholder  needs  (BKCASE  Editorial  Board  2016). 

1.  Functional  Decomposition 

The  HADR  OMP  system  functions  and  decomposition  diagram  are  derived  from 
the  operational  concept  and  mission  requirements,  and  show  the  operational  functions 
and  support  behaviour  the  platform  must  perform  to  meet  mission/stakeholder 
requirements.  It  is  important  to  understand  the  various  functions  necessary  for  overall 
HADR  operations  in  order  to  develop  a  functional  decomposition  for  the  HADR  OMP. 
The  platform  functional  decomposition  is  similar  but  distinct  given  the  focus  on 
managing  and  coordinating  HADR  operations  vice  developing  functions  to  conduct  every 
aspect  of  the  operations.  The  modes  of  operation  identified  in  the  operational  concept  are 
used  as  the  basis  for  many  of  the  high  level  functions.  Figure  19  provides  the  high  level 
functional  decomposition.  Each  of  these  high  level  functions  will  be  further  described  in 
the  proceeding  paragraphs. 
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Figure  19.  HADR  OMP  High  Level  Functional  Decomposition  Diagram 
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2.  Functional  Requirements 

A  review  of  the  needs  of  HADR  operations,  coupled  with  the  functional  analysis, 
resulted  in  eight  top-level  functions  and  sub-level  functions.  Many  of  these  functional 
requirements  are  based  on  the  modes  of  operation  described  previously,  and  an 
accumulation  of  the  literature  research  conducted.  These  functions  are  described  in  the 
proceeding  sections. 

a.  Provide  Assessments  and  Analysis 

The  "Provide  Assessments  and  Analysis”  (1.0)  function  shown  in  Figure  20 
contains  four  sub-functions:  (1.1)  Provide  Affected  Population  Needs  based  information, 
(1.2)  Provide  Foundational  Information,  (1.3)  Provide  Search  and  Rescue  Information, 
(1.4)  Provide  Assessment  Analysis. 

Each  sub-function  brings  a  specific  functionality  to  the  OMP.  The  (1.1)  sub- 
function  provides  the  ability  to  effectively  conduct  needs  assessments  to  understand  the 
severity  and  level  of  support  needed  by  the  affected  population.  Sub-function  (1.2) 
provides  the  ability  to  quickly  understand  reference  information  about  the  country  and 
affected  people  in  which  the  HADR  effort  is  taking  place.  Finally,  sub-function  (1.3) 
provides  the  ability  to  quickly  assess  and  prioritize  requests  for  help  in  life  threatening 
situations.  Finally,  sub-function  (1.4)  provides  the  tools  that  aid  in  analyzing  the  data  to 
be  effective  for  the  various  functions  being  addressed  within  the  HADR  operations. 

In  the  case  of  (1.1),  tools  include,  but  are  not  limited  to,  needs,  gaps,  and 
constraints  analysis  and  the  ability  to  prioritize  and  categorize  information. 
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Figure  20.  Assessment  and  Analysis  Function 

b.  Provide  Planning  Mechanisms 

The  “Provide  Planning  Mechanisms”  (2.0)  function  shown  in  Figure  21 
encompasses  four  sub-functions:  (2.1)  Set  Objectives,  Targets,  and  Indicators,  (2.2) 
Provide  Planning  &  Guidance  Communication  Mechanisms,  (2.3)  Provide  Roles  & 
Responsibilities  (R&R)  Communication  Mechanisms,  (2.4)  Provide  Accountability  of 
Operations. 

Sub-function  (2.1)  provides  the  ability  to  identify  indicators  and  targets  that  can 
be  tracked  and  continuously  assessed  to  meet  overall  objectives  of  the  HADR  response. 
In  addition,  sub-function  (2.2)  provides  tools  that  will  aid  in  the  communication  of 
strategic,  operational,  and  tactical  planning  and  guidance  of  the  operations.  Sub-function 
(2.3)  delivers  the  ability  to  quickly  establish  roles  and  responsibilities  of  various 
stakeholders  supporting  the  HADR  response  effort.  Finally,  sub-function  (2.4)  provides 
the  ability  to  ensure  that  there  is  proper  accountably  through  the  HADR  operations  by 
clearly  defining  roles  &  responsibilities  and  establishing  tracking  metrics. 

Regarding  (2.3),  a  large  portion  of  these  responsibilities  should  be  pre-established 
prior  to  a  HADR  event  occurring.  However,  it  will  be  necessary  to  define  more  specific 
roles  and  responsibilities  to  various  location  sectors.  Tools  should  be  established  to 
communicate  these  roles  and  responsibilities. 
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Figure  21.  Planning  Mechanisms  Function 

c.  Provide  Resource  Mobilization 

The  “Provide  Resource  Mobilization”  (3.0)  function  shown  in  Figure  22 
envelopes  three  sub-functions:  (3.1)  Provide  Personnel  and  Supply  Resource  Status,  (3.2) 
Provide  Personnel  and  Supply  Resource  Request,  and  (3.3)  Provide  Personnel  and  Supply 
Resource  Tasking  and  Allocation. 

Each  sub-function  traces  to  lower  tier  sub-functions  that  it  delivers  to  the  system. 
The  sub-function  (3.1)  delivers  the  ability  to  status  where  all  HADR  materials  are  located 
and  their  current  status  (inventory,  transit,  onsite,  etc.).  It  also  provides  the  ability  to 
maintain  logs  of  supplies  and  provides  the  ability  to  status  where  all  HADR  personnel  are 
located  and  their  current  status  (on  locate,  in-route,  etc.).  Finally,  sub-function  (3.1) 
provides  the  ability  to  develop  contact  lists. 

Sub-function  (3.2)  presents  two  lower  tier  sub-functions.  The  first  is  the  ability  for 
Cluster  Leads  or  Site  Leads  to  input  requests  for  additional  supplies  such  as  food,  water, 
and  medicine.  The  second  is  the  ability  for  Cluster  Leads  or  Site  Leads  to  input  requests 
for  additional  personnel  to  aid  in  HADR  response  efforts. 

Sub-function  (3.3)  traces  to  four  lower  tier  sub-functions.  The  first  is  the  ability  to 
transport  supplies  where  needed  within  an  identified  timeframe.  Second,  sub-function 
(3.3)  provides  tools  that  aid  in  optimization  of  supply  routes  and  allocation  of  supplies  to 
desired  locations.  Third,  it  affords  the  ability  to  allocate  personnel  where  needed  within 
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an  identified  timeframe.  Finally,  sub-function  (3.3)  provides  tools  that  aid  in  optimization 
of  personnel  resources  to  cover  the  needs  of  the  overall  HADR  effort  to  meet  identified 
objectives. 
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Figure  22.  Resource  Mobilization  Management  Function 

d.  Provide  Command  and  Control  (C2)  Implementation  &  Monitoring 

The  “Provide  Command  and  Control  Implementation  and  Monitoring”  (4.0) 
function  shown  in  Figure  23  divides  into  four  sub-functions:  (4.1)  provide  Situational 
Awareness  (Common  Operating  Picture);  (4.2)  provide  Essential  Cluster  Function 
Coordination;  (4.3)  provide  Search  &  Rescue  Teams  Status  &  Requests;  and  (4.4) 
provide  Monitoring,  Tracking,  Metrics,  and  Alert  Notifications. 

The  (4.1)  sub-function  provides  the  system  with  a  COP  capable  of  ensuring  that 
all  HADR  actors  responsible  for  making  decisions  during  the  response  have  access  to  the 
correct  information  necessary  to  make  timely  decisions.  Further,  sub-function  (4.2)  grants 
the  ability  to  provide  status  immediate  health  services,  food/nutrition,  food  security, 
protection,  shelter,  camp  management,  water,  sanitation,  hygiene  products,  education, 
and  early  recovery  services  to  the  affected  population.  Sub-function  (4.3)  provides  the 
ability  to  status  Search  and  Rescue  operations  to  include,  manning,  equipment,  and 
information.  It  also  delivers  the  ability  to  task  or  send  requests  for  aid  to  specific  Urban 
Search  and  Rescue  (USAR)  teams,  and/or  provide  them  with  the  COP  to  help  them  task 
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based  on  their  resources  available.  Finally,  (4.4)  grants  the  ability  to  monitor  and  track 
logistics,  supplies,  HADR  response  personnel,  search  and  rescue,  cluster  performance 
(progress  of  response  based  on  defined  objectives),  safety  and  security  levels,  etc.,  on  the 
COP.  In  addition,  it  provides  the  ability  to  track  metrics  on  the  COP  of  progress  towards 
the  identified  Objectives,  Targets,  and  Indicators.  Provide  alert  notifications  to  identified 
stakeholders. 
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Figure  23.  Command  and  Control  (C2)  Implementation  and  Monitoring  Function 
e.  Provide  Communication  Mechanisms 

The  “Provide  Communication  Mechanisms”  (5.0)  function  shown  in 
Figure  24  sub-divides  into  four  sub-functions:  (5.1)  Provide  Information  to  Affected 
Population,  (5.2)  Provide  Liaison/  Collaboration  Mechanisms,  (5.3)  Provide  Foreign 
Military  Collaboration  Mechanisms,  (5.4)  Provide  Operational  Review  &  Evaluation. 

The  (5.1)  sub-function  delivers  the  ability  to  communicate  information  to  the 
affected  population  that  is  necessary  to  aid  in  alleviating  suffering.  This  includes  tools  for 
finding  missing  persons,  providing  medical,  food,  and  water  location  information,  etc. 
The  (5.2)  sub-function  grants  the  ability  to  collaborate  at  multiple  levels  with  multiple 
organizations  in  an  effective  manner  to  meet  agreed  to  objectives.  Provide  tools  to 
quickly  define  collaboration  and  communication  mechanisms  if  not  previously 
established.  The  (5.3)  sub-function  delivers  the  ability  to  incorporate  communication 
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tools  specific  to  foreign  military  support  collaboration  at  the  operational/tactical  levels. 
These  tools  should  include  the  ability  to  quickly  define  collaboration  and  communication 
procedures  if  not  previously  established.  Finally,  the  (5.4)  sub-function  gives  responders 
and  affected  populations  the  ability  to  provide  feedback  and  to  document  lessons  learned 
from  the  response. 
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Figure  24.  Communication  Mechanisms  Function 

/.  Provide  Ops  Support 

The  “Provide  Ops  Support”  (6.0)  function  shown  in  Figure  25  expands  into  four 
sub-functions:  (6.1)  Provide  Personnel  &  Administration  Management,  (6.2)  Provide 
Information  Management,  (6.3)  Provide  Management  of  Financial  Needs  &  Tracking, 

Each  of  these  sub-functions  on-boards  a  critical  OMP  function.  The  (6.1)  sub- 
function  delivers  tools  for  managing  the  inflow/outflow  of  personnel  in  the  HADR 
response  zone,  maintaining  contact  lists,  providing  tools  for  funds  transfers  and  tracking. 
The  (6.2)  sub-function  provides  the  ability  to  manage  the  information  and  make  it  easily 
accessible  to  users.  This  includes  the  collection,  processing,  analysis,  visualization,  and 
dissemination  of  information.  The  (6.3)  sub-function  endows  the  platform  with  the  ability 
to  manage  financial  needs,  and  track  inflow/outflow  of  funds  provided  to  support  the 
HADR  effort.  Finally,  the  (6.4)  sub-function  provides  the  ability  for  virtual  volunteers  to 
support  the  OMP.  This  can  include  the  functions  described  previously  in  Figure  15. 
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Figure  25.  HADR  Operations  Support  Function 
g.  Provide  System  Support 

The  “Provide  System  Support”  (7.0)  function  shown  in  Figure  26  expands  into 
five  sub-functions:  (7.1)  Provide  System  Management;  (7.2)  Provide  System  Security; 

(7.3)  Provide  Network  Management;  (7.4)  Provide  System  Support  Infrastructure;  and 
(7.5)  Provide  Training  &  IT  Support. 

The  (7.1)  sub-function  ensures  that  all  the  HADR  OMP  software  applications  and 
components  are  working  properly,  and  includes  the  ability  to  manage  the  software 
applications  that  are  developed.  These  software  applications  support  the  functionality  of 
the  platform  to  the  user.  The  (7.2)  sub-function  provides  the  system  security  of  the 
HADR  OMP  and  ensures  that  the  platform  is  protected  against  unauthorized  access.  The 

(7.3)  sub-function  bestows  the  ability  to  monitor  platform  communication  status  and 
outages  and  ensures  the  OMP  is  operating  in  expected  parameters  on  the  network.  The 

(7.4)  sub-function  ensures  the  necessary  platform  infrastructure  is  provided  to  support  the 
HADR  OMP.  This  includes  software,  hardware,  and  network  communications.  One  of 
the  lower  level  third  tier  sub-functions  under  (7.4)  would  include  interoperability  to  meet 
MOE  7.0  described  in  Table  5.  Finally,  the  (7.5)  sub-function  provides  the  necessary 
training  that  is  required  for  HADR  responders  to  interface  with  the  platform.  This  sub- 
function  also  provides  the  support  necessary  to  fix  technical  problems  with  the  platform 
while  in  operation. 
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Figure  26.  HADR  OMP  System  Support  Function 

3.  HADR  OMP  Function  Traceability 

It  is  important  to  show  traceability  of  the  HADR  OMP  functions  back  to  the 
MOEs.  By  showing  traceability  it  ensures  that  all  the  essential  stakeholders’  needs, 
mission  objectives,  and  MOEs  are  through  the  functions  of  the  platform.  Table  7  provides 
the  traceability  to  the  MOEs  that  were  identified  previously  in  Table  5. 
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Table  7.  HADR  OMP  Functional  Traceability  Matrix 


HADR  OMP  Functional  Traceability  Matrix 
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B.  LOGICAL  ARCHITECTURE  DEFINITION 


The  next  step  in  the  system  definition  process  is  developing  the  logical 
architecture  of  the  system  (also  known  as  a  functional  allocated  architecture).  The  logical 
architecture,  defines  what  the  system  must  do  to  meet  the  functional  requirements 
identified  previously  (Buede  2009,  27).  The  logical  design  provides  the  major  functions 
and  system  boundaries  of  the  platform  along  with  their  relationships.  This  allows  for 
more  detailed  system  design  to  be  developed.  The  high  level  data  flows  and  connections 
are  also  defined.  The  initial  logical  architecture  is  used  to  ensure  all  components  and 
functionality  necessary  is  accounted  for  and  is  well  understood  within  the  platform 
(TechieDolphin  2006).  The  proposed  logical  architecture  presented  is  an  initial 
assessment  that  can  be  approved  upon  with  additional  stakeholder  feedback  and  future 
iterations. 


1.  Organizational  Interaction  Behavior  Model 

The  organizational  interaction  for  HADR  operations  can  be  very  complex  with 
multiple  organizations  from  multiple  countries  helping  to  support  the  host  government 
and  affected  population  in  the  humanitarian  response  effort.  Figure  27  provides  the  high 
level  organizational  view  of  the  many  stakeholders  involved  in  HADR  operations  and 
how  these  stakeholders  will  interact  with  the  HADR  OMP.  This  interaction  with  the 
platform  is  important  to  understand  how  best  to  develop  the  coordination  mechanism 
applications,  the  Graphical  User  Interfaces  (GUIs),  and  to  ensure  that  all  stakeholders’ 
requirements  are  being  met. 
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Figure  27.  Interaction  Organization  Behavior  Model  for  HADR  OMP 


2.  Information  Flow  between  Application  Components 

The  information  flow  that  will  be  required  for  the  platform  is  very  dynamic  with 
large  amount  of  information  used  to  support  many  different  application  components. 
Figure  28  provides  an  example  of  the  information  flow  that  will  be  required  between  the 
various  application  components  of  the  platform.  This  diagram  can  aid  in  identifying  the 
more  detailed  input  and  output  data  requirements  for  each  application  component  in  the 
detailed  system  design.  The  flow  of  information  within  the  platform  will  be  managed  by 
the  data  management  module. 
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Figure  28.  High  Level  Data  Information  Flow  for  the  HADR  OMP 


3.  HADR  OMP  Components 

The  logical  architecture  shown  in  Figure  29  provides  the  HADR  OMP 
components.  These  components  are  primarily  software  application  components  and 
platform  support  components.  The  components  are  divided  into  four  primary  system 
components:  modes  of  operations,  support  to  operations,  system  support,  and 
coordination  mechanisms.  The  software  application  components  provide  the  necessary 
functions,  tasks,  or  activities  that  will  be  required  by  the  various  users.  The  architecture 
also  shows  the  system  boundaries  with  GUI  visualizations  as  the  primary  output.  The 
option  for  exportable  data  features  or  data  sharing  with  other  external  systems  may  also 
be  a  consideration  during  the  finalization  of  the  system  definition. 
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Figure  29.  HADR  OMP  Logical  Architecture 
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4. 


Function  Traceability  to  System  Application  and  Platform  Support 
Components 


Based  on  the  functions  developed  previously,  components  of  the  HADR  OMP 
were  identified.  These  HADR  OMP  components  identified  in  the  logical  architecture  in 
Figure  29  are  traced  back  to  the  high  level  OMP  functions  identified  previously  in 
Figure  19.  These  components  are  made  up  of  software  applications  and  platform  support, 
and  provide  the  functionality  necessary  to  meet  mission  objectives  and  stakeholder 
requirements  during  various  modes  of  operation.  Table  8  provides  the  traceability  matrix 
back  to  the  high  level  functions. 


62 


Table  8.  Software  Application  and  Platform  Support  Components 

Traceability 


HADR  OMP  Software  Application  &  Platform  Support  Components  Traceability  Matrix 


Figure  30  provides  a  pictorial  representation  of  the  traceability  between  the 
stakeholders,  coordination  mechanisms,  modes  of  operation,  identified  data  sources,  and 
functional  decomposition  to  the  identified  components  of  the  platform.  Now  that  the 
various  high  level  functions  and  components  of  the  HADR  OMP  have  been  identified 
definition  of  the  logical  architecture  can  begin  to  be  refined. 
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Figure  30.  Traceability  to  HADR  OMP  Components 
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5. 


Common  Operating  Picture  User  Interface 


The  Common  Operational  Picture  (COP)  is  a  map  with  overlaid  information  that 
can  be  filtered  from  multiple  data  sources.  This  information  would  include  personnel  and 
supply  locations  while  in-route  to  tasked  locations,  damage  assessment  information, 
requests  for  help  by  survivors  via  social  media  or  other  means  such  as  SMS  texting. 
Other  relevant  features  can  also  be  provided  from  satellite  and  drone  imagery.  In  general 
the  COP  is  a  large  “fused  meta-data  crisis  map,”  that  multiple  decision  makers  in  various 
roles  can  utilize  to  support  the  humanitarian  operations  effort.  Figure  31  provides  an 
example  of  a  COP  that  can  be  displayed  to  a  HADR  responder  on  their  tablet.  This 
example  COP  is  currently  under  development  by  MicroMappers  (Meier  2014). 


Figure  31.  Example  COP.  Source:  Meier  (2014). 

6.  Mapping  Current  Technology  to  the  Platform  and  Applications 

Many  technologies  were  accessed  during  the  background  and  research  phase  of 
this  thesis.  No  single  consolidated  platform  currently  exists  to  effectively  manage  HADR 
operations,  however,  there  are  many  new  applications  and  platforms  providing 
information  and  capabilities.  Many  of  these  new  applications  and  platforms  are  still  in 
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development  or  in  beta  testing,  and  are  helping  to  contribute  to  support  HADR 
operations.  If  these  tools  and  applications  are  combined  into  a  single  platform  they  will 
be  more  effective  in  aiding  decision  makers  in  various  functional  areas  and  at  various 
levels  (strategic,  operational,  and  project  levels).  The  existing  applications  shown  in 
Figure  32  and  Figure  33  were  identified  during  the  research  phase,  and  are  potential  data 
sources  and  applications  to  be  incorporated  into  the  platform  to  meet  the  system 
requirements.  Additional  information  on  these  technologies  can  be  found  in  Appendix  A. 


Figure  32.  Applications  Identified  for  Incorporation  into  the  Platform. 
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Figure  33.  Data  Sources  and  Applications  to  Meet  Functions  within  the  Platform. 

C.  PHYSICAL  ARCHITECTURE 

The  last  step  in  the  system  definition  process  is  developing  the  physical 
architecture  of  the  system.  The  physical  architecture  provides  the  physical  resources 
necessary  for  every  function  identified  in  the  logical  architecture.  Every  phase  of  the 
system  life  cycle  should  be  considered  when  developing  the  physical  architecture  (Buede 
2009,  253). 


1.  Platform  Hardware  in  Theater 

As  part  of  the  HADR  OMP,  deployable  hardware  units  will  be  necessary.  This 
includes  the  use  of  ruggedized  laptops  and  desktop  computers,  a  projector  system, 
communications  system  with  radios,  phones,  webcam,  and  conferencing.  A  fax/printer/ 
copier  with  a  backup  will  also  be  required  as  well  as  a  deployable  half  rack  (15  units)  of 
hardware  to  support  the  local  substantiation  of  the  platform.  The  half  rack  includes 
switches,  router,  servers  for  local  processing,  a  raid  unit  for  local  storage,  and 
uninterruptible  power  supply  (UPS)  unit  to  protect  against  power  shortages,  and  a  power 
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strip.  These  deployable  units  would  be  small  enough  to  be  transported  on  two  standard 
shipping  pallets,  and  be  provided  to  the  On-Site  Operation  Coordination  Center 
(OSOCC),  the  National  Emergency  Operations  Center  (NEOC),  the  Multi-National 
Military  Coordination  Center  (MNMCC),  the  logistics  cluster,  and  one  unit  as  a  backup. 
Mobile  backup  hard  drives  will  also  be  required  for  additional  mobile  use  if  the  network 
communications  system  is  down.  Figure  34  provides  a  high  level  diagram  of  the 
deployable  hardware  units  that  will  be  required  at  the  primary  operations  centers,  and  the 
mobile  hardware  to  support  data  collection  for  the  COP  by  HADR  Responders.  The 
mobile  hardware  includes  ruggedized  smartphones  (iPhone  and  Android  operating 
systems),  tablets,  and  smart  watches.  This  hardware  aids  in  communication  and  relaying 
of  information  from  the  field  to  include  damage  assessments,  needs  assessments,  requests 
for  additional  resources,  and  geo-tracking  of  personnel.  From  the  telecommunication 
standpoint,  it  is  expected  that  the  Telecommunications  cluster  will  provide  the  necessary 
terrestrial  and  satellite  communications  hardware  to  maintain  a  communication  point-of- 
presence  (PoP)  node  for  the  platform  in  theater. 
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Figure  34.  Deployable  Hardware  Units  to  Support  the  HADR  OMP 

2.  Software  Module  and  Service  Decomposition 

To  support  the  various  software  applications  components,  a  software  architecture 
will  need  to  be  developed.  The  module  decomposition  architecture  shown  in  Figure  35 
was  developed  displaying  the  system  boundaries  and  module  decomposition  to  support 
the  logical  architecture  for  the  HADR  OMP.  These  modules  decompose  the  solution  into 
elements  that  provide  the  functions  identified  in  the  system  requirements  phase  (Klein  et 
al.  2016).  A  reference  architecture  initially  introduced  to  support  big  data  systems  in  the 
national  security  domain  was  used  as  a  starting  point  due  to  the  similarities  in  supporting 
the  HADR  OMP  information  management  and  analysis  functions,  such  as  collection, 
processing,  analysis,  visualization,  and  dissemination  of  information  (Klein  et  al.  2016). 
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Table  9  provides  a  purpose  description  of  the  various  modules  necessary  to  support  the 
functions  of  the  platform.  These  module  descriptions  are  slightly  modified  for  application 
to  the  HADR  OMP  from  a  paper  presented  at  the  2016  International  Workshop  on  Big 
Data  Software  Engineering  titled,  “A  Reference  Architecture  for  Big  Data  Systems  in  the 
National  Security  Domain”  (Klein  et  al.  2016). 


Figure  35.  HADR  OMP  Software  Module  Decomposition.  Adapted  from 

Klein  et  al.  (2016). 
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Table  9. 


_ Modules _ 

Application 

Integration 

Module 

Collection  Module 


Module  Descriptions  for  the  HADR  OMP  Based  on  Reference 
Architecture.  Adapted  from  Klein  et  al.  (2016). 


Data  Analysis 
Module 


Applications 

Module 


Mobile 

Applications 

Module _ 

Visualization 

Module 


Description 


Application  Framework 


Data  Processing 
&  Integration 
Module 


Application  Integration  configures  and  combines  other  modules  in  the  application 
provider,  integrating  activities  into  a  cohesive  application  platform.  An 
application  is  the  end-to-end  data  processing  through  the  system  to  perform 
specific  tasks  determined  by  the  use  cases. 

The  collection  module  interfaces  with  the  external  data  providers,  and  ensures  that 
the  data  coming  in  is  managed  appropriately  by  an  established  data  model, 
ensuring  the  characteristics  and  constraints  of  the  data  is  managed  appropriately  to 
prevent  data  loss.  For  this  module  work  effectively.  Standardization  of  data  inputs 
will  be  necessary,  and/or  the  ability  to  translate  data  in-line  with  the  data  model. 

The  main  purpose  of  the  external  data  processing  (EDP)  module  is  transforming 
data  to  make  it  useful  for  the  other  modules  downstream.  It  performs  the 
transformation  portion  of  the  traditional  Extract,  Transform  Load  (ETL)  cycle, 
including  tasks  such  as: 

•  Data  validation  (e.g.,  checksum  validation); 

•  Cleansing  (e.g.,  removing  or  correcting  bad  records); 

•  Optimization  (e.g.,  de-duplication); 

•  Schema  transformation  and  standardization; 

•  Indexing  to  support  fast  lookup. 

The  EDP  module  may  perform  basic  enrichment,  which  adds  information  from 
other  sources  to  a  data  record.  Later,  the  Data  Exploitation  &  Analysis  Module 
can  perform  more  sophisticated  enrichment,  for  example,  using  a  recommendation 
engine  to  create  new  associations  to  other  records. 

The  data  analysis  module  works  to  extract  relevant  information  from  the  data  to 
be  provided  for  exploitation  and  analysis.  Within  this  module  there  is  also  a  sub- 
module.  The  virtual  volunteer  sub-module  is  responsible  for  providing  data 
sources  to  be  analysed  and  exploited  by  the  virtual  volunteer  community.  This 
data  includes  social  media  information  (Tweets,  Facebook,  SMS  messages,  etc.), 
satellite  imagery,  drone  footage,  etc. 

Initially,  a  human-in  the  loop,  will  be  required  to  perform  the  overall  analysis, 
exploitation,  and  validation  within  the  platform  by  utilizing  analysis  tools, 
however,  the  goal  should  be  to  automate  as  much  as  possible  to  ensure  timeliness 
of  information  dissemination. 

This  module  provides  the  internal  and  external  applications  that  are  required  to 
meet  the  functional  requirements  of  the  platform,  and  are  broken  down  into 
application  components.  These  applications  are  shown  in  the  logical  architecture 
diagram. 

This  module  provides  the  mobile  applications  that  are  required  to  meet  the 
functional  requirements. 

The  visualization  module  provides  the  graphical  user  interfaces  (GUIs)  from 
processed  data,  the  outputs  of  the  analytics,  and  internal/external  applications  to 
the  user.  Within  this  module  there  are  three  sub-modules:  Common  Operating 
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Modules 


Description 


Application  Framework 


Picture  (COP),  dashboard,  and  visual  analytics.  The  COP  module  provides  the 

GUIs  responsible  for  creating  the  dynamic,  on-demand  generation,  and  interactive 
COP  map  with  layers  of  information  that  can  be  shown  or  removed  with  a  click  of 
a  button.  The  dashboard  sub-module  will  provide  GUIs  of  various  dashboards, 
which  includes  various  tools  and  applications  that  can  be  used  by  the  users.  The 
visual  analytics  module  will  provide  the  GUIs  necessary  to  perform  analysis  and 
validation  on  the  data  collected. 

Access  Module 

The  access  module  allows  various  stakeholders  to  gain  access  to  the  HADR  OMP, 
and  provides  access  to  various  GUIs  and  information  based  on  the  user  profile. 

This  module  is  also  the  go-between  with  external  systems,  and  is  used  to  enforce 
the  security  rule-sets  and  permission  determined  in  the  security  management 
module. 

Service  Support  Fn 

imework 

System 

Processing 

Module 

The  Processing  module  ensures  efficient,  scalable,  and  reliable  execution  of 
analytics.  It  provides  the  processing  hardware  necessary  to  support  the  system. 

The  HADR  OMP  will  distribute  the  processing  logic  and  execute  it  locally  on  the 
same  nodes  where  data  is  stored,  transferring  only  the  results  of  processing  over 
the  network.  The  system  processing  module  will  also  need  the  ability  to  not  lose 
data  in  the  event  of  a  process  or  node  failure  within  the  framework  (ability  to 
recover). 

Messaging 

Module 

The  messaging  module  provides  reliable  queuing,  transmission,  and  delivery  of 
data  and  control  functions  between  application  components. 

Data  Storage 
Module 

The  data  storage  provides  reliable  and  efficient  access  to  the  data.  This  includes 
the  logical  data  organization,  data  distribution  and  access  methods,  and  data 
discovery  (using  e.g.,  metadata  services,  registries  and  indexes). 

The  data  organization  and  access  methods  will  be  concerned  with  the  data  storage 
format  (e.g.,  flat  files,  relational  data, 

structured/unstructured  data)  and  the  type  of  data  access  required. 

The  data  storage  module  will  ensure  the  availability  and  consistency  of  the  data 
over  a  distributed  system. 

Infrastructure 

Module 

The  infrastructure  module  provides  the  infrastructure  resources  necessary  to  host 
and  execute  the  activities  of  the  HADR  OMP.  A  physical  architecture  will  be 
proposed  in  the  proceeding  section. 

Cross-Cutting  Mod 

ules 

System 

Management 

Module 

The  system  management  module  includes  the  monitoring,  configuration, 
provisioning  and  control  of  infrastructure  and  applications. 

Data 

Management 

Module 

Data  organization  is  very  important  with  high  volumes  of  data  inputs.  If  done 
incorrectly,  it  can  significantly  impact  the  performance  of  the  platform.  Data 
Management  is  involved  in  all  the  activities  of  the  life  cycle  to  include  collection, 
data  processing,  integration,  analytics,  visualization,  and  access  to  the  system. 
Standardization  of  data  will  help  aid  in  the  management. 

Security  Module 

The  security  module  is  responsible  for  controlling  access  to  the  data  and 
applications  within  the  platform,  and  is  responsible  for  enforcement  of  access 
rules  and  restricting  access  based  on  user  profiles.  This  modules  is  also 
responsible  for  protection  against  intrusion  from  hacking  or  other  nefarious 
activities. 
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3.  Distributed  Computing  and  Network  Architecture 

The  platform’s  networking  architecture  must  be  dynamic,  manageable,  cost- 
effective,  and  adaptable  to  meet  the  mission  and  stakeholder  requirements.  The  platform 
must  also  have  the  ability  to  adapt  to  new  applications  and  data  sources  as  the  system 
grows.  For  this  reason  a  software-defined  networking  (SDN)  architecture  with  distributed 
computing  is  proposed  to  support  the  HADR  OMP  (Cisco  2016). 

Distributed  computing  will  be  necessary  to  aid  in  the  vast  amounts  of  processing 
that  will  be  required.  Some  of  these  data  processing  servers  may  already  exist  and  can  be 
utilized  with  partnerships  between  governments,  UN-OCHA,  IGOs,  and  NGOs.  It’s 
possible  that  the  majority  of  data  processing  can  take  place  in  a  location  outside  of  the 
HADR  zone  with  processed  data  provided  infield  for  fusion  into  the  COP  and  local  data 
repository  to  support  the  platform  applications.  This  allows  for  the  hardware  units  being 
deployed  into  theater  to  be  smaller  and  more  easily  transportable,  allows  for  additional 
reliability  of  the  platform  due  to  the  unpredictability  of  communications  and  power  in  a 
HADR  zone.  The  systems  will  also  need  to  function  when  telecommunications  are  down 
due  to  this  unreliability,  thus  backup  offline  systems  will  be  part  of  the  deployable 
hardware  necessary  to  support  the  platform.  Figure  36  provides  a  proposed  Network 
Architecture  for  the  HADR  OMP.  However,  as  part  of  the  follow-on  effort  a  more 
thorough  trade-space  analysis  should  be  conducted  with  a  networking  team  to  ensure  that 
the  best  solution  is  implemented. 
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Access  Server 


Figure  36.  HADR  OMP  Distributed  Computing  Network  Architecture.  Adapted 

from  Microsoft  (2016). 
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VI.  CONCLUSION  AND  RECOMMENDATIONS 


This  thesis  addressed  the  initial  concept  development  and  system  definition  of  a 
HADR  Operational  Management  Platform  (OMP)  to  be  used  by  various  stakeholders 
involved  in  time  critical  humanitarian  response  efforts.  It  includes  inputs  from  multiple 
sources  of  information,  and  explores  ways  to  provide  information  and  tools  to  more 
effectively  manage  HADR  efforts.  The  HADR  OMP  includes  a  common  operating 
picture  for  better  situational  awareness,  collection  management  and  analysis,  information 
sharing  and  data  management,  along  with  software  based  collaboration  and  functional 
tools  to  support  the  various  modes  of  HADR  operation. 

During  the  writing  of  this  thesis  three  primary  research  questions  were  addressed. 
The  first  question  asked,  “What  are  the  functions  and  operational  requirements  for 
HADR  operations,  and  how  can  these  requirements  be  managed  more  efficiently  through 
the  use  of  a  HADR  OMP?”  This  question  was  addressed,  first,  by  using  system 
engineering  processes  and  tools  during  the  mission  analysis  phase  to  create  a  mission 
scenario,  identifying  the  problem  space,  developing  an  operational  concept,  and 
identifying  key  stakeholders’  needs.  This  led  to  the  HADR  OMP  MOEs,  which  are  the 
initial  operational  requirements  for  the  system.  From  there,  the  functions  of  the  HADR 
OMP  were  identified  and  decomposed  with  traceability  back  to  the  MOEs. 

The  second  question  asked,  “What  type  of  data  and  technologies  can  be  utilized  to 
support  a  management  platform?”  This  question  was  addressed  in  the  system  definition 
phase.  High  level  functions  of  the  HADR  OMP  were  developed  along  with  a  proposed 
logical  and  physical  architecture.  This  allows  for  the  identification  of  existing  technology 
to  include  new  data  sources  and  software  based  applications  that  have  the  potential  be 
incorporated  into  the  HADR  OMP  to  meet  the  functional  requirements  necessary  for  the 
platform. 

The  third  question  asked,  “How  can  “virtual  volunteers”  most  effectively  be 
utilized  to  help  in  HADR  operations?”  For  the  purposes  of  this  thesis,  virtual  volunteers 
are  defined  as  people  volunteering  their  time  to  conduct  tasks  to  support  the  HADR 
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response  effort  via  their  computers  over  an  internet  connection.  This  question  was 
addressed  by  exploring  the  functions  and  roles  that  virtual  volunteers  can  have  to  support 
a  HADR  event,  and  incorporating  the  ability  for  these  virtual  volunteers  to  be 
incorporated  into  the  HADR  OMP. 

The  next  step  is  to  refine  the  concept  and  system  definition  by  receiving  feedback 
from  stakeholders  involved  in  HADR  operations  to  ensure  all  necessary  requirements  are 
captured  appropriately  and  that  the  proposed  solution  meets  the  needs  as  expected.  In 
addition,  partnerships  will  need  to  be  made  between  many  humanitarian  organizations 
with  agreements  for  sharing  data.  UN-OCHA  would  need  to  endorse  and  lead  the  effort 
on  creating  the  platform  as  well  as  advocacy  from  multiple  humanitarian  response 
stakeholders.  Standards  for  data  sharing  will  need  to  be  agreed  upon  with  externals 
starting  with  the  Humanitarian  Exchange  Language  (HXL)  standard  as  the  baseline. 

In  addition,  with  the  potential  for  new  technologies  to  aid  in  HADR  operations 
there  are  also  concerns  and  new  challenges  that  are  faced.  When  utilizing  open  source 
technologies  such  as  crisis  mapping  and  crowdsourcing  for  HADR  operations  many 
questions  need  to  be  considered.  For  example,  the  “Humanitarianism  in  the  Network 
Age,”  OCHA  Policy  and  Studies  Series,  asks  the  following  questions: 

•  How  do  you  know  how  accurate  the  information  is? 

•S  What  is  the  confidence  level  of  the  information  being  provided? 

S  How  subjective  vs.  objective  is  the  interpretation  of  the  data? 

•S  How  do  you  know  if  the  data  hasn’t  been  manipulated? 

•  If  the  data  is  shared,  can  it  negatively  impact  the  population  at  risk  due  to 
local  conflicts? 

•  How  do  you  ensure  that  biases  are  not  made  in  decision  making  to  help 
those  who  have  higher  level  access  to  mobile  and  network  technology? 

•  Is  the  HADR  operations  platform  secure  from  hackers  or  malware  (UN¬ 
OCHA  2013, 8)? 
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This  thesis  touched  on  these  areas  indirectly,  but  did  not  address  them 
specifically.  More  detailed  design  should  be  completed  to  ensure  that  these  questions  are 
thoroughly  answered. 

Engineering  teams  will  need  to  be  created  to  further  define  the  solution  for  the 
platform.  This  includes  further  development  and  detailed  design  of  the  platform 
applications,  application  interfaces,  visualizations,  data  management  (including  “big 
data”),  network  architecting,  network  management,  software  management  services, 
training  programs,  and  deployment  hardware.  Follow-on  research  and  trade-space 
analysis  should  be  conducted  to  more  thoroughly  assess  the  existing  platforms,  new  data 
sources  and  software  based  applications  that  can  be  incorporated  into  the  HADR  OMP. 
During  the  writing  of  this  thesis,  many  new  software  applications  to  support  HADR 
operations  are  still  in  development. 

Finally,  the  system  definition  should  include  an  agile  software  development 
process  that  allows  for  expandability,  flexibility,  and  adaptability  with  open  source 
software,  and  should  meet  other  pre-defined  quality  attributes.  A  listing  of  the  quality 
attributes  can  be  found  in  Appendix  B.  The  outputs  of  the  system  definition  phase  are 
used  moving  forward  into  the  system  realization  phase  and  include  the  implementation, 
integration,  verification,  and  validation  of  the  system  prior  to  deployment.  A  prototype 
should  be  created  to  aid  in  the  development  of  the  platform,  and  allow  for  applications  to 
be  added  easily  for  testing  for  functionality  and  interoperability  with  already  existing 
applications.  The  development  of  training  courses  and  IT  support  teams  will  need  to  be  in 
included  in  this  development. 
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APPENDIX  A:  TECHNOLOGY  AND  DATA  SOURCE  ASSESSMENT 


Survivors  and  disaster  relief  responders  now  use  social  media  and  electronic 
communications  during  crises  to  save  lives.  The  increased  prevalence  of  socially-sourced 
information  has  led  to  interactive  “LIVE”  mapping  during  humanitarian  aid  and  disaster 
relief  efforts.  For  instance,  the  2010  Haiti  Earthquake  was  one  of  the  first  crises  where 
crisis  mapping  was  used  to  support  rescue  and  recovery  operations.  After  the  earthquake, 
text  messages  were  translated  and  placed  on  maps  by  “virtual  volunteers”  to  help  aid  in 
the  relief  effort. 

Social  media  has  also  grown  at  an  exponential  rate  in  the  past  five  years.  As  of 
2015,  over  +1.71  billion  people  have  Facebook  accounts  (Facebook  2016)  and  313 
million  have  active  Twitter  accounts  (Twitter  2016).  In  addition  to  its  role  in  people’s 
daily  lives,  social  media  can  communicate  crisis-relevant  information,  such  as  victim 
locations  and  infrastructure  damage  (UN-OCHA  2013).  Figure  37  shows  the  most 
popular  social  networking  sites  by  country  (Cosenza  2016). 


Figure  37.  Most  Popular  Social  Networking  Sites  by  Country. 

Adapted  from  Cosenza  (2016). 
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Humanitarian  agencies  are  finding  new  ways  to  aggregate  and  display  information 
for  decision  makers.  They  are  searching  for  rapid,  low-cost,  and  accurate  solutions  to 
dynamic  situations  by  incorporating  new  applications,  like  crowd  sourcing  and  crisis 
mapping,  into  their  operations.  According  to  “Humanitarianism  in  the  Network  Age,” 
OCHA  Policy  and  Studies  Series,  2012,  “either  organizations  adapt  to  the  network  age,  or 
they  grow  increasingly  out  of  touch  with  the  people  they  were  established  to  serve”  (UN¬ 
OCHA  2013,  11). 

A.  CRISIS  MAPPING 

According  to  Patrick  Meier,  an  internationally  recognized  leader  in  applications 
of  new  technologies  for  crisis  mapping,  Crisis  Mapping  is  “live  mapping  focused  on 
crises  (purposely  broad  because  it  can  be  applied  to  many  types  of  crises)  to  include 
political,  social,  and  environmental”  (Meier  2009).  Crisis  Mapping  is  where  “scholars, 
practitioners,  and  communities  alike  work  together  to  create,  analyse,  visualize  and  use 
real-time  data  for  humanitarian  response  and  post-conflict  reconstruction  and 
development”  (Meier  2009). 

Crisis  mapping  utilizes  social  media,  texting,  and  other  data  sources  to  help  show 
the  most  up-to-date  information  on  a  dynamic  map  that  can  be  continuously  updated. 
Crisis  mapping  relies  on  crowd  sourcing,  in  which,  in  broad  terms,  is  defined  as  the 
“practice  of  obtaining  needed  services,  ideas,  or  content  by  soliciting  contributions  from  a 
large  group  of  people,  and  especially  from  an  online  community,  rather  than  from 
traditional  employees  or  suppliers”  ( Merriam-Webster  Dictionary  2014).  Crowd  sourced 
information  comes  from  two  primary  sources,  the  populace  in  the  affected  community 
and  trusted  individuals  like  humanitarian  aid  workers  and  registered  volunteers.  This 
latter,  more  specific,  form  of  crowdsourcing  is  known  as  crowd  seeding. 

MicroMappers  is  a  joint  initiative  between  UN-OCHA,  Qatar  Computing  Research 
Institute  (HBKU),  and  the  Standby  Task  Force.  According  to  their  website, 
MicroMappers  “is  a  crowdsourcing  platform  for  consuming  &  classifying  news,  images, 
YouTube,  aerial  imagery,  satellite  imagery”  (Meier  2014).They  have  activated  crisis 
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maps  in  recent  natural  disasters  such  as  the  Ecuador  Earthquake  in  April  2016,  the  Nepal 
Earthquake  in  April  2015,  and  the  Vanuatu  Cyclone  Pam  in  March  2015. 

B.  HUMANITARIAN  ID 

Humanitarian  ID  is  a  contact  management  application  created  by  UN-OCHA  and 
provides  tools  for  humanitarian  responders  be  to  find,  connect,  and  collaborate  at  the 
onset  of  a  major  disaster.  It  allows  responders  to  develop  a  personal  profile,  provide 
contact  details,  and  prepare  to  support  a  crisis  ahead  of  time.  Once  registered,  responders 
can  check  into  the  country/emergency.  Responders  can  also  develop  a  local  profile  when 
they  support  a  specific  humanitarian  effort,  join  groups  that  are  associated  with  the  effort, 
check-in  once  they  reach  the  disaster  location,  and  receive  relevant  information  related  to 
the  coordination  of  the  disaster.  If  security  risks  are  high,  only  verified  users  can  view 
other  profile  and  contact  information  {Humanitarian  ID  2015). 

Humanitarian  ID  also  helps  coordinators  find  responders  that  are  working  in  their 
sector,  and  can  manage  their  contact  lists.  Managers  can  also  better  understand  the 
capacity  and  personnel  gaps  within  the  various  sectors  in  the  disaster  region 
{Humanitarian  ID  2015).  Humanitarian  ID  is  a  possible  solution  to  support  personnel  and 
administration  management  within  the  HADR  OMP. 

C.  BIG  DATA  ANALYSIS 

Big  Data  analysis  provides  correlation  and  analysis  of  large  quantities  of  data, 
which  can  provide  surprising  insights  into  the  HADR  operations  environment  (UN¬ 
OCHA  2013,  7).  The  challenge  with  Big  Data  is  how  to  take  massive  datasets  useful  to 
decision  makers  in  near-real-time  situations  while  avoiding  information  overload.  (UN¬ 
OCHA  2013,  26).  The  issue  of  managing  information  overload  is  out  of  scope  to  this 
thesis;  however,  it  is  important  to  understand  that  Big  Data  will  play  a  greater  role  in 
HADR  operations  than  ever  before  now  and  into  the  future.  The  software  decomposition 
of  the  HADR  OMP  is  based  on  a  Big  Data  reference  architecture  initially  introduced  to 
support  big  data  systems  in  the  national  security  domain  (Klein,  et  al.  2016).  Future 
development  of  the  HADR  OMP  should  include  Big  Data  analysis. 
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D.  HUMANITARIAN  DATA  EXCHANGE 


The  Humanitarian  Data  Exchange  (HDX)  is  a  database  developed  by  UN-OCHA 
as  an  open  repository  for  sharing  information  related  to  humanitarian  and  disaster  relief 
efforts,  and  is  searchable  by  the  public.  As  of  July  2016,  the  HDX  included  over  4,057 
datasets  from  244  locations  worldwide  with  over  769  sources  of  information  (UN-OCHA 
2016).  The  HDX  has  many  uses  from  a  global  strategic  standpoint  in  planning  and 
advocating  for  humanitarian  efforts. 

The  HDX  project  is  working  towards  providing  humanitarian  data  real-time  to 
governments,  aid  agencies,  and  affected  people  (Kobylinski  2014).  However,  it  is  unclear 
how  this  information  will  be  effectively  used  to  aid  HADR  efforts  at  the  operational 
level.  Future  development  of  the  HADR  OMP  should  explore  tradeoffs  for  including  the 
HDX  into  the  overall  architecture  or  as  a  data  source. 

E.  HUMANITARIAN  DATA  EXCHANGE  STANDARDS 

In  2015,  UN-OCHA  released  their  1.0  Beta  of  the  Humanitarian  Exchange 
Language  (HXL)  standard.  HXL  helps  various  humanitarian  organizations  by  creating  a 
data  standard  for  automation  and  interoperability.  This  standard  helps  data  to  be 
recognized  and  merged  with  other  sources  of  data  more  efficiently.  Figure  38  shows 
examples  of  the  various  hashtags,  tagging,  and  attributes  that  can  help  support  the 
consolidation  of  data  between  humanitarian  agencies  (Megginson  2015).  The  HADR 
OMP  can  incorporate  the  HXL  standard  into  the  architecture  design  and  requirements  to 
ensure  that  data  is  more  easily,  collected,  processed  and  shared  with  external  data 
sources. 
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WhatisHXL? 

HXL  is  a  different  kind  of  data  standard, 
designed  to  improve  information  sharing 
during  a  humanitarian  crisis  without 
adding  extra  reporting  burdens. 

HXL-tagging  data 


Organisation 

Cluster 

District 

#org 

#sector 

#adml 

Org  A 

WASH 

Coast 

Org  B 

Health 

Mountains 

Org  C 

Education 

Coast 

Add  HXL  tags  between  the  last  row  of 
headers  and  the  first  row  of  data. 

Use  attributes  like  +code  to  refine  tags. 

If  you  need  to  create  new  tags,  start 
them  with  #x_  (e.g.  #x_virulence). 


Some  suggested  attributes 

People  Impact  Dates 

+f  +killed  +start 

+m  +injured  +end 

+i  +infected  +reported 

+infants  +displaced 

+children  +idps  Geography 

+adolescents  +refugees  +lat 
+adults  +incamp  +lon 

+elderly  +noncamp  +bounds 

Tag  +  attribute  examples 

#adml  +code  Admin  1  P-code 

#affected  +f  Females  affected 

#geo  +bounds  +url  Link  to  shape  file 
#description +fr  French  description 

#meta+source  Data  source 


Figure  38.  HXL  Beta  1.0  Release  -  Tagging  and  Attributes.  Source:  Megginson 

(2015). 


F.  GDACS  AND  THE  VOSOCC 

The  Global  Disaster  Alert  and  Coordination  System  (GDACS)  is  a  framework 
developed  in  a  partnership  between  the  United  Nations,  the  European  Commission,  and 
other  disaster  relief  organizations.  The  system  was  developed  to  improve  alerts, 
information  exchange,  and  coordination  during  the  initial  phase  after  a  major  disaster. 
(GDACS  2015).  The  GDACS  includes  the  Virtual  On-Site  Operations  Coordination 
Center  (VOSOCC)  to  help  with  collaboration  and  coordination  of  activities.  In  contrast, 
the  On-Site  Operations  Coordination  Center  (OSOCC)  is  a  local  rapid  response  center 
used  for  coordination  and  facilitation  of  international  relief,  and  also  supports  and 
coordinates  with  the  Host  Nation.  The  OSOCC  is  a  focal  point  for  the  HADR  OMP,  and 
is  described  in  greater  detail  in  the  operation  concept  section. 

The  VOSOCC  is  a  computer  based  real-time  online  coordination  platform  that 
exchanges  information  between  stakeholders  in  the  initial  phase  of  a  disaster.  This 
information  includes:  baseline  country  information,  socio-economic  background, 
demographics,  logistical  support  data,  relief  team  status,  cluster  activities,  assessment 
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information,  Civil-Military  coordination  status,  environmental  concerns,  and  security 
risks  (UN-OCHA,  FCSS  2014). 

Although  the  VOSOCC  has  been  used  in  HADR  operations,  the  system  is  still 
fairly  new  with  room  for  enhancements.  It  is  setup  similar  to  a  SharePoint  site  with 
access  to  information,  but  does  not  provide  an  overall  common  operating  picture  (COP) 
with  all  the  necessary  tools  to  manage,  coordinate,  and  operate  a  humanitarian  response. 
This  results  in  a  need  for  a  more  interactive  HADR  OMP  to  integrate  these  necessary 
capabilities.  The  VOSSOC  is  an  existing  platform  that  could  potentially  be  incorporated 
into  the  HADR  OMP. 

G.  GDACS  LIVE  MAPPING 

Included  in  the  GDACS  is  an  interactive  live  crisis  map  that  includes  geo-spatial 
data  from  multiple  sources.  The  Live  Map  GDACS  system  works  to  integrate  satellite 
imagery  and  field  data  to  support  HADR  operations  by  providing  damage  assessment 
information  on  a  live  interactive  map.  Location  tagged  photos  are  automatically  uploaded 
from  the  UN-ASIGN  smartphone  app  (UNOSAT  2015).  Figure  39  provides  an  example 
of  the  Live  Map  GDACS  system.  The  downside  to  the  Live  Map  GDACS  system  is  that 
other  organizations  are  creating  their  own  crisis  maps  that  don’t  necessary  talk  to 
GDACS  leaving  gaps  in  data  collection.  The  Live  Map  GDACS  is  an  existing  platform 
that  should  be  considered  for  incorporation  into  the  HADR  OMP  or  as  a  data  source. 
Other  crisis  map  platforms  should  also  be  considered  such  as  MicroMappers 
(MicroMappers  2014). 
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Figure  39.  GDACS  Live  Mapping  UNOSAT  (2015). 

H.  GOOGLE  CRISIS  RESPONSE 

Google  Crisis  Response  is  a  branch  within  Google.org  that  works  to  utilize  the 
capabilities  available  at  Google  to  support  humanitarian  efforts.  Some  of  these  efforts 
include  information  flow,  crisis  mapping,  data  sharing,  and  donation  support  for 
humanitarian  organizations.  Some  of  the  tools  that  Google  has  developed  include:  Google 
Person  Finder,  Google  Crisis  Mapping,  and  Google  Public  (Google  2015). 

Google  has  been  known  to  set  up  24/7  support  centers  after  major  disasters  to  aid 
in  response  efforts.  According  to  Joint  Publication  3-29,  after  the  2011  Fukushima 
nuclear  power  plant  crisis  in  Japan,  Google  engineers  provided  free  training,  analysis, 
crowd  sourcing  tools,  and  overhead  imagery  tools  to  operational  planners  responsible  for 
maintaining  the  nuclear  facility  (Joint  Publication  3-29  2014). 
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One  of  the  notable  tools  that  Google  developed  is  the  Google  Person  Finder, 
which  enables  disaster  victims  to  reestablish  communication  with  their  family  members 
and  friends  following  a  HADR  event.  This  tool  was  initially  developed  by  Google  after 
the  2010  Haiti  earthquake.  The  source  code  available  at  github.com  for  outside 
developers  to  improve  the  tool,  government  and  nonprofit  organizations  can  download 
data  into  Google  Person  Finder  or  synchronize  with  existing  databases  (Google  2015). 

I.  THE  MOBILE  GDACS 

Mobile  smartphone  applications  were  developed  to  disseminate  GDACS  HADR 
information  to  responders  as  fast  as  possible.  “iGDACS”  is  a  mobile  app  that  allows 
responders  to  get  the  latest  alert  and  key  statistical  information  on  their  iPhone.  It  also 
allows  feedback  to  be  provided  on  HADR  events  to  be  sent  to  others  in  the  GDACS 
community.  UN-ASIGN  is  one  of  the  applications  produced,  and  is  available  on  both 
Android  and  iPhones.  It  is  a  fully  operational  crowd-source  application  that  is  used  to 
provide  geo-located  photos  and  text  messages  back  to  the  Live  GDACS  map.  The 
application  is  designed  to  work  over  low  bandwidths  and  in  offline  conditions  for  areas 
that  have  unstable  access  to  internet  connections  (GDACS  2015). 

J.  DRONE  TECHNOLOGY 

Unmanned  Aerial  Vehicles  (UAVs),  also  known  as  “drones,”  played  a  major  role 
in  the  Nepal  2015  earthquake  HADR  response  effort.  With  a  shortage  of  available 
helicopters,  drones  were  used  to  collect  damage  assessment  information,  which  allowed 
helicopters  to  focus  on  critical  rescue  missions.  It  is  expected  that  drones  will  be  used  in 
increasing  numbers  into  the  future.  They  can  provide  comprehensive  data  collection  and 
mapping  capabilities.  Drones  can  cover  as  much  as  5  to  10  square  km  in  a  few  hours, 
complementing  slower  ground-based  field  surveys.  They  are  also  deployed  below  cloud 
cover  that  can  hamper  satellite  imagery  collection  (Team  Rubicon  2015). 
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Supportability  is  an  important  element  in  the  design  process,  and  is  typically  the 
most  significant  element  impacting  the  operations  and  support  costs.  These  costs  are 
typically  the  largest  contributor  to  the  total  life-cycle  costs  of  a  system.  According  to  the 
2009  PHD  NSWC  MSSE/MSSEM  Cohort  6  Capstone  Project  Report,  supportability 
includes  the  “provision  of  maintenance,  training,  test  equipment,  technical 
documentation,  supply  support,  facilities,  transportability,  human  systems  interfaces,  and 
other  non-functional  requirements”  (Capstone  Project  Report,  PHD  NSWC  MSSE/ 
MSSEM  Cohort  6  2009,  10).  These  requirements  help  to  ensure  the  system  in 
development  is  usable,  reliable,  and  maintainable  throughout  its  life  cycle.  Supportability 
requirements  will  need  to  be  developed  for  the  HADR  operations  management  platform, 
and  will  focus  on  ensuring  the  system  can  be  supported  in  a  cost  effective  manner 
(Capstone  Project  Report,  PHD  NSWC  MSSE/MSSEM  Cohort  6  2009). 

Functional  properties  of  the  system  itself  such  as  modifiability,  reusability, 
testability,  etc  are  known  as  quality  attributes.  These  quality  attributed  effect  the 
supportability  and  performance  of  the  system.  Figure  40  shows  the  HADR  OMP 
objective  hierarchy  with  quantified  quality  attributes.  Table  10  lists  the  quality  attributes 
and  definitions  as  defined  by  the  2009  PHD  NSWC  MSSE/MSSEM  Cohort  6  Capstone 
Project  Report,  with  slight  modification  for  application  to  this  thesis  (Capstone  Project 
Report,  PHD  NSWC  MSSE/MSSEM  Cohort  6  2009,  484). 
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Figure  40.  HADR  Operations  Management  Platform  Quality  Attributes  Objective 
Hierarchy.  Adapted  from  Capstone  Project  Report,  PHD  NSWC 
MSSE/MSSEM  Cohort  6  (2009). 
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Table  10.  Quality  Attribute  Definitions.  Adapted  from  Capstone  Project  Report, 

PHD  NSWC  MSSE/MSSEM  Cohort  6  (2009). 


Quality  Attributes 

Definition 

Functionality 

The  ability  of  the  system  to  do  the  work  for  which  it  was  intended. 

Performance 

The  response  time,  utilization,  and  throughput  behavior  of  the  system. 

Security 

A  measure  of  system’s  ability  to  resist  unauthorized  attempts  at  usage  or  behavior  modification,  while 
still  providing  service  to  legitimate  users. 

Availability 

The  measure  of  time  that  the  system  is  up  and  running  correctly;  the  length  of  time  between  failures 
and  the  length  of  time  needed  to  resume  operation  after  a  failure. 

Usability 

The  ease  of  use  and  of  training  the  end  users  of  the  system. 

Interoperability  The  ability  of  two  or  more  systems  to  cooperate  at  runtime. 

Modifiability 

The  ease  with  which  a  software  system  can  accommodate  changes  to  its  software. 

Portability 

The  ability  of  a  system  to  run  under  different  computing  environments.  The  environment  types  can  be 
either  hardware  or  software,  but  is  usually  a  combination  of  the  two. 

Reusability 

The  degree  to  which  existing  applications  can  be  reused  in  new  applications. 

Integrability 

The  ability  to  make  the  separately  developed  components  of  the  system  work  correctly  together. 

Testability 

The  ease  with  which  software  can  be  made  to  demonstrate  its  faults 

Conceptual 

Integrity 

The  integrity  of  the  overall  structure  that  is  composed  from  a  number  of  small  architectural  structures. 

Correctness 

Accountability  for  satisfying  all  requirements  of  the  system.  Sensitivity  The  degree  to  which  a  system 
component  can  pick  up  something  being  measured. 
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Change  Traffic 

Change  traffic  is  a  measure  of  the  rate  at  which  software  modification  is  required.  It  is  a  complex 
function  of  requirements  stability,  software  integrity  and  system  operation. 

Change  traffic  will  affect  the  volume  of  software  support  activity.  Higher  change  traffic  will  require 
more  software  modification  work.  Change  traffic  may  only  be  measured  during  actual  use  of  the 
system. 

Before  the  software  is  in  use,  estimates  may  be  made  by  comparison  with  similar  applications  and 
projections  from  requirements  change  and  fault  detection  rate  metrics  taken  during  the  software  and 
system  testing  and  trials.  Any  data  available  from  comparable  in-service  systems  on  change  traffic  and 
effort  will  also  be  of  significant  value. 

Safety  Integrity 

The  safety  integrity  required  of  a  software  item  will  be  determined  by  consideration  of  the  safety 
criticality  of  the  functions  that  it  provides.  Safety  criticality  relates  to  the  likelihood  of  anomalies  in  the 
system  causing  accidents  of  varying  severity. 

The  overall  safety  criticality  of  a  system  should  be  established  by  the  application  of  an  appropriate 
hazard  analysis  technique.  The  criticality  of  particular  software  items  will  be  consequent  upon  the 
partitioning  of  system  functions  in  the  system  design. 

Designs  should  aim  to  minimize  and  isolate  software,  which  implements  highly  critical  functions. 
System  requirements  should  define  safety  criticality  categories  and  specify  appropriate  software  safety 
integrity  levels.  Various  constraints  and  requirements  for  software  development,  testing  and 
modification  will  be  associated  with  each  safety  integrity  level. 

Expansion 

Capability 

Expansion  capability  is  an  attribute  of  system  design.  It  is  concerned  with  the  degree  to  which  software 
may  be  modified  without  being  limited  by  constraints  on  computing  resources.  Associated  physical 
limitations,  such  as  space,  are  to  be  addressed  in  the  context  of  the  parent  system.  Examples  of 
constraints  on  computing  resources  are: 
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(a)  Available  memory. 

(b)  Processor  performance. 

(c)  Mass  storage  capacity. 

(d)  Input/Output  bandwidth. 

Inadequate  expansion  capability  might  limit  the  scope  for  software  modification  or  significantly  impact 
on  modification  costs.  Even  simple  changes  might  involve  significant  amounts  of  rework  to  overcome 
system  limitations. 

Limited  expansion  capability  is  of  particular  relevance  in  the  case  of  embedded,  real-time  applications. 

In  such  cases  it  is  normal  to  state  spare  capacity  requirements  as  part  of  any  procurement  specification. 

Size  and 

Disposition 

The  number  of  equipment  in  use,  and  locations  at  which  software  support  is  conducted,  will  have  an 
impact  on  software  supportability  requirements  and  support  costs.  Significant  sub-groups  of  users 
might  generate  requirements  for  variations  of  the  software  to  suit  their  specific  needs.  The  number  and 
distribution  of  equipment  will  influence  the  magnitude  of  the  software  support  task  and  the  optimum 
location  of  the  software  support  facilities.  Moreover,  large  operational  units  are  more  likely  to 
accumulate  higher  levels  of  equipment  usage,  thereby  increasing  the  probability  of  fault  detection  and 
the  identification  of  corrective  change  requirements. 

Modularity 

Modularity  is  an  attribute  of  the  low-level  structure  of  a  software  design,  and  relates  to  the  extent  to 
which  processes  and  functions  are  represented  as  discrete  design  elements.  The  modularity  exhibited 
by  a  particular  design  will  be  a  function  of  the  engineering  practices  applied  by  the  developer,  and 
factors  determined  by  the  choice  of  design  method,  tools  and  programming  language. 

However,  in  general  the  optimum  approach  to  modularity  will  be  one  that  balances  functional  and 
performance  requirements  against  the  need  to  provide  an  understandable  and  supportable  design.  Poor 
modularity  might  result  in  increased  modification  costs  owing  to  the  need  to  implement  consequential 
changes  in  other  parts  of  the  software. 
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Requirements  for  interface  control  and  standardization  might  be  used  to  influence  the  modularity  of  a 
system  design. 

Size 

A  number  of  metrics  are  available  to  quantify  software  size.  The  size  of  a  software  item  might 
influence  its  supportability,  both  in  terms  of  the  level  of  change  traffic  expected  and  the  resources 
required  to  implement  a  change.  The  size  of  the  software  within  a  system  is  dependent  upon  the 
application  and  the  design  solution  Software  requirements  should  state  any  constraints  on  the  size  of 
run-time  software  imposed  by  the  system  design. 

Many  software  support  and  supportability  projections  will  be  based  on  estimates  of  software  size  and 
complexity.  Software  development  requirements  should  specify  requirements  for  data  collection  and 
analysis  to  measure  software  size,  and  to  verify  any  models  or  estimates  of  supportability  parameters 
that  depend  on  software  size. 

Security 

The  security  classification  of  data,  executable  code  and  documentation  might  impose  constraints  and 
demands  on  the  software  support  activities  and/or  the  Project  Support 

Environment  (PSE).  The  main  influence  on  a  prime  equipment  will  be  to  impose  special  handling 
requirements.  These  might  limit  access  to  the  software  and  introduce  design  requirements,  which  give 
rise  to  specific  software  support  tasks  and  equipment. 

The  security  classification  of  a  software  item  will  be  dependent  upon  the  application  and  the  equipment 
design.  Wherever  possible  systems  should  be  designed  such  that  highly  classified  software  is 
physically  segregated  from  all  other  software  within  a  system.  System  security  requirements  should 
provide  criteria  for  security  classification  of  software  items  and  should  specify  modification  and 
handling  constraints  associated  with  such  classifications. 

Skills 

Software  modification  will  require  personnel  with  appropriate  software  engineering  skills. 

Requirements  for  particular  skills  might  be  associated  with  the  application  domain,  the  technology  or 
the  methods  used.  Skill  requirements  will  be  determined  by  the  system  design,  the  software  design  and 
the  chosen  software  support  policy.  Skill  requirements  will  have  an  impact  on  personnel  and  training 
needs. 
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Standardization 

Standardization  may  be  applied  to  the  computing  environment  within  which  the  software  executes,  and 
to  the  technologies  and  engineering  processes  used  to  develop  the  software  and  the  associated  software 
documentation.  Standardization  will  benefit  software  supportability  by  reducing  the  diversity  of  tools, 
skills  and  facilities  required. 

The  scope  for  standardization  across  a  system  might  be  constrained  by  the  overall  architectural  design. 
Standardization  requirements  should  be  included  within  system  and  software  requirements.  Software 
standardization  requirements  might  be  less  rigorously  applied  to  software,  which  will  only  be 
supported  by  the  original  developer  utilizing  existing  facilities,  personnel  and  equipment. 

Software  standardization  requirements  should  avoid  constraining  the  design  to  software  technology, 
which  has  limited  life  expectancy  or  no  clear  evolutionary  path. 

Technology 

Technology  should  be  considered  in  respect  of  the  software  engineering  methods  and  tools  used  in 
development  and  implementation  together  with  the  hardware  and  software  aspects  of  both  the  host  and 
target  platforms. 

Technology  issues  might  include:  specification  and  software  design  methods  and  supporting  tools; 
operating  systems,  programming  languages  and  compilers;  software  test  methods  and  environments; 
project  specific  tools  and  techniques;  processing  architectures. 

Requirements  for  the  use  of  specific  technologies  might  impose  constraints  on  the  system  and  software 
design  solutions;  they  will  also  affect  software  engineering  productivity  and  integrity. 

Tools  and 

Methods 

The  selection  of  tools  and  methods  is  dependent  on  the  technologies  used  to  develop  and  implement 
the  system.  The  use  of  particular  tools  or  methods  might  influence  the  software  productivity  and 
integrity  achieved  during  software  modification.  The  cost  of  acquiring  and  supporting  tools  should  be 
carefully  considered,  since  it  might  influence  the  selection  of  the  software  support  policy. 

Depending  on  the  level  of  standardization  achieved,  the  same  tools  and  facilities  might  be  used  to 
support  software  items  from  one  or  more  systems.  Selection  of  the  tools  and  methods  to  be  used  during 
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software  development  is  a  design  decision  and  will  form  part  of  the  design  solution. 

The  selected  toolset  will  normally  be  incorporated  in  a  PSE,  which  would  also  provide,  depending  on 
the  chosen  support  policy,  the  basis  for  the  post-delivery  support  environment  for  the  software. 

The  tools  within  a  PSE  will  require  support  throughout  the  life  of  the  prime  system  to  which  they 
relate,  since  the  tools  themselves  will  experience  change,  upgrade  and  obsolescence. 

System  developers  should  have  a  strategy  for  considering  these  issues  in  their  initial  toolset  selection 
and  for  on-going  management  of  overall  toolset  effectiveness  and  integrity  during  the  system  life  cycle. 
Aspects  which  should  be  considered  in  respect  of  each  potential  tool  supplier  include  the  following: 

(a)  Commercial  viability  and  track  record. 

(b)  Quality  of  customer  service  arrangements. 

(c)  Product  upgrade  policy,  particularly  in  respect  of  the  maintenance  of  functional  compatibility 
between  succeeding  software  versions  and  the  continued  provision  of  support  for  preceding  versions. 

Documentation 

The  term  documentation  refers  to  all  records,  electronic  or  hardcopy,  that  relate  to  the  requirements, 
specification,  analysis,  design,  implementation,  testing  and  operation  of  a  software  item.  In  order  to 
ensure  software  supportability  the  documentation  must  be  produced  to  an  agreed  standard  and  it  must 
be  available  to  the  organization  charged  with  delivering  software  support.  Any  software  tools  used  in 
the  creation  of  documentation  must  be  included  in  the  support  facility  and  arrangements  must  be 
defined  for  their  through-life  support. 
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